Functioneel ontwerp Centrale Vegetatiedatabank (CVD)

Transcriptie

1 Functioneel ontwerp Centrale Vegetatiedatabank (CVD) Erik van der Zee Peter van den Pol Nick Naus 19 februari 2016

2 Functioneel Ontwerp - Centrale Vegetatiedatabank Je bouwt toch ook geen huis zonder een ontwerp? Datum / 106

3 Colofon Documentinformatie Titel Functioneel Ontwerp Centrale Vegetatiedatabank Projectnaam Centrale Vegetatiedatabank Projectcode ITP15262 Document ID Datum 19 februari 2016 Status Definitief Filenaam ITP15262 FO Centrale Vegetatiedatabank BIJ12_v1.0.docx Auteurs Erik van der Zee Peter van den Pol Nick Naus Opdrachtgever Erik Lubberink Organisatie BIJ12 Eigenaar Naam Erik Lubberink Rol Wijzigingshistorie Versie Status Datum Beschrijving Auteur(s) 0.1 Concept Eerste opzet structuur FO + EvdZ, PvdP, NN Toevoegen van eerste content 0.2 Concept Aanpassing document structuur EvdZ, PvdP, NN aan BIJ12 template 0.3 Concept Uitbreiden use cases en EvdZ, PvdP, NN gebruikers 0.5 Concept Aanpassingen naar aanleiding van EvdZ, PvdP, NN workshop II 0.9 Concept Vastgesteld door BIJ12 NN, PvdP 1.0 Definitief Vastgesteld door BIJ12 en PIN EvdZ, PvdP Interne en externe toets (review) Versie Datum Opmerkingen Intern Geodan Tekstuele en methodische review BIJ12 Stakeholders Structurele en Inhoudelijke review PIN leden Laatste review Interne en externe distributielijst Versie Datum Organisatie Aan BIJ12 Dick Bal (EZ), Jaap Bauwman (Unie van Bosgroepen), Rene Bekker (BIJ12), Piet Bremer (Overijssel), Joost Buiks (RWS), Hennie Blikman (Natuurmonumenten), Flip Dirkse (RWS), Ivo Eggink (BIJ12), Marlies Ellenbroek (BIJ12), Meinte Engelmoer (Fryslan), Jaap Graveland (RWS), Stephan Hennekes (Alterra), Jan Holtland (Staatsbosbeheer), Berry Lucas (12 landschappen), Peter van der Molen (BIJ12), Johannes Regelink (Netwerk Groene Bureaus), Marti Rijken (Gelderland), Michiel Schram (EZ), Frans Spruijt (RWS), Tjeerd Wits (BIJ12) Datum / 106

4 Managementsamenvatting Doelstelling van de Centrale Vegetatie Databank (CVD) is dat gegevens over vegetatie, habitattypen en structuur beter, eenduidiger en met een duidelijker kwaliteitslabel beschikbaar komen binnen de Digitale Keten Natuur. Het doel van dit document is te komen tot een functioneel ontwerp voor de CVD. Dit functioneel ontwerp borduurt voort op de uitgangspunten van de eerder opgestelde PSA. Het opstellen van het functioneel ontwerp is de volgende stap richting realisatie van de CVD. Het functioneel ontwerp wordt gebaseerd op de uitganspunten die in de PSA zijn uitwerkt. Het Functioneel Ontwerp biedt inzicht in de buitenkant van een applicatie, en bevat een beschrijving van te ontwikkelen functionaliteiten. Een Functioneel Ontwerp (FO) laat stap voor stap zien hoe gebruikers (mensen maar ook externe systemen) interacteren met de applicatie. Aangezien beide typen gebruikers (mensen en externe systemen) gebruik zullen gaan maken van de Centrale Vegetatiedatabank zullen in dit FO zowel de GUIs als APIs worden uitgewerkt. De belangrijkste onderdelen van het FO zijn de volgende: Algemene uitgangspunten / hoofdrequirements Beschrijving van gebruikersgroepen Functionele beschrijving van de drie datapackages Use Cases vanuit het gebruikersperspectief De use cases die in dit FO zijn uitgewerkt zijn: 1. Inloggen op het CVD systeem 2. Account aanvragen, username vergeten, password vergeten 3. Contact, Help, Sitemap 4. Proclaimer, Colofon 5. Aanmaken package zonder NMS 6. Importeren package 7. Zoeken mijn packages 8. Basis Zoeken en Raadplegen (packages) 9. Geavanceerd Zoeken en Raadplegen (packages) 10. Valideren packages (technisch) 11. Valideren packages (kwaliteit) 12. Landelijke Kaarten 13. Catalogi beheren 14. Users beheren 15. Rapporten beheren 16. Uploaden packages via API door NMS 17. Zoeken (en downloaden) via API door NMS Het FO is SMART opgesteld en dient als startpunt voor de realisatiefase voor de CVD. Datum / 106

5 Inhoudsopgave Managementsamenvatting Inleiding Context en aanleiding Waarom een FO? Doelstelling FO Resultaten FO Afbakening (scope) FO Betrokken bij totstandkoming Aanpak Gehanteerde methodieken Leeswijzer Hoofdstukindeling Lijst van figuren Lijst van tabellen Overkoepelende requirements Introductie van de CVD Waarom een CVD? Wat is de CVD Kaderstellende documenten Requirements CVD Overview gebruikersgroepen en CVD Overall requirements Data requirements Koppelingen Voorkomen en stijl Gebruikersgemak en personalisatie Performance Onderhoud en Ondersteuning Veiligheid (security) Juridisch Detaillering requirements Datapackages van de CVD Wat zijn DataPackages? Type packages Packages inhoudelijk (bron IMNa) Implementatie packages in uitwisselstandaarden XML Package Desktop Package Legacy Package Gebruikers van de CVD Typen gebruikers Overzicht gebruikers Detaillering gebruikers Medewerker TBO met natuurmanagementsysteem Medewerker TBO zonder natuurmanagementsysteem Medewerker ecologie RWS Datum / 106

6 4.3.4 Beleidsmedewerker (natuur) provincie Medewerker groenbureau Beleidsmedewerker ministerie van Economische Zaken Medewerker onderzoeksinsitituut / onderwijsinstelling Applicatie interface structuur en flow Applicatie interface structuur Header Menu Functioneel blok Footer Links naar externe applicaties Applicatie flow diagram Use cases Use Case Overzicht Samenhang tussen de use cases (use case model) Use Case Inloggen Use Case Aanvragen account Use Cases Contact, Help, Sitemap Use Cases Proclaimer, Colofon Use Case Aanmaken Package zonder NMS Use Case Importeren Package(s) Use Case Mijn Packages Use Case Basis Zoeken en Raadplegen Packages Use Case Geavanceerd Zoeken en Raadplegen Use Case Technisch Valideren Package(s) Use Case Kwaliteitslabelen Package(s) Bronhouder validatie (intern) Autoriteit validatie (extern) Use Case Raadplegen Landelijke Kaarten Beheer Use Case Catalogusbeheer Beheer Use Case Userbeheer Beheer Use Case Rapportenbeheer API beschrijvingen API Use Case Uploaden packages via API door NMS API Use Case Zoeken en downloaden via API door NMS Bijlage A Referenties Bijlage B - Terminologie Bijlage C Voorbeeld CVD API Bijlage D Workshop verslagen Workshop I dinsdag 1 december Workshop II donderdag 17 december Bijlage E Interview verslagen Datum / 106

7 1 Inleiding 1.1 Context en aanleiding Als onderdeel van het project Centrale Vegetatiedatabank wordt er een Functioneel Ontwerp opgesteld. De functionele scope van de CVD is als volgt gedefinieerd [zie PSA CVD pagina 19]: De CVD is een registervoorziening gericht op het gestructureerd valideren, vastleggen en beschikbaar maken van data. De CVD is geen inwin-, reken-, analyse- of beoordelingstool. De CVD heeft betrekking op de uitwisseling en het vastleggen van de datadomeinen: vegetatiegegevens (inclusief afgeleide abiotiek), habitattypen, structuurgegevens en landelijke beelden voor habitattypen en vegetatietypen. Koppelingen naar aanleverende systemen waaronder inwinsystemen (zoals Turboveg), Bedrijfssystemen (zoals CMSi) en geo-systemen (zoals van de provincies t.b.v. habitattypenkaarten). Koppelingen naar afnemende systemen, zoals rekenmodules voor Natuurkwaliteit NNN, Natura 2000/PAS en INSPIRE datapublicatie. Na het opstellen van een PSA in de periode augustus oktober 2015 is de volgende stap het uitwerken van het functioneel ontwerp en daaraan gekoppelde eisen en wensen. 1.2 Waarom een FO? Een goede voorbereiding op de ontwikkeling van een applicatie is het opzetten van een Functioneel Ontwerp. Het Functioneel Ontwerp biedt inzicht in de buitenkant van een applicatie, en bevat een beschrijving van te ontwikkelen functionaliteiten. Een Functioneel Ontwerp (FO) laat stap voor stap zien hoe gebruikers (mensen maar ook externe systemen) interacteren met de applicatie. Voor Mensen is een grafische user interface (GUI) de manier om te interacteren met een applicatie Voor Externe Systemen is een Application Programming Interface (API) de manier om te communiceren met een applicatie Aangezien beide typen gebruikers (mensen en externe systemen) gebruik zullen gaan maken van de Centrale Vegetatiedatabank zullen in dit FO zowel de GUIs als APIs worden uitgewerkt. GUIs worden uitgewerkt in wireframes. Een wireframe is een voorbeeldscherm binnen een internet browser dat uitbeeldt hoe de functionaliteit van de applicatie gaat werken, en hoe de interactie tussen mens en applicatie gaat verlopen. Een application programming interface is een connector (soort stopcontact ) waarmee een extern systeem kan communiceren met een applicatie. De beschrijving van een API is vaak online via een website beschikbaar. Het ontwerpen van de API is geen onderdeel van dit functioneel ontwerp. In overleg met de toekomstige gebruikers moet worden bepaald hoe het systeem zich moet gedragen en hoe er mee samengewerkt moet worden. Hoe moet het samenspel tussen gebruiker en systeem zijn, zodat het werkproces van de gebruiker optimaal kan worden ondersteund en uitgevoerd? Datum / 106

8 De functionele aspecten hebben betrekking op: de te verrichten bewerkingen (en de volgorde ervan); de te verwerken invoer; de te bewaren gegevensverzameling; de te produceren uitvoer; de gewenste/vereiste prestatie. Belangrijk is de betrokkenheid van de gebruikers bij het detailleren van de functies en het vaststellen van de gewenste kwaliteit van de te vervaardigen producten. 1.3 Doelstelling FO De opdracht heeft als doel te komen tot een functioneel ontwerp voor de Centrale Vegetatie Database. Dit functioneel ontwerp borduurt voort op de uitgangspunten van de eerder opgestelde PSA. Het opstellen van het functioneel ontwerp is de volgende stap richting realisatie van de CVD. Het functioneel ontwerp wordt gebaseerd op de uitganspunten die in de PSA zijn uitwerkt. Het FO is SMART opgesteld en kan in combinatie met een TO worden uitgewerkt in test cases. Waar de functionaliteit nog niet tot in detail is uitgewerkt dient het als uitgangspunt voor een iteratief (SCRUM) proces. 1.4 Resultaten FO Dit functioneel ontwerp richt zich op het concretiseren van de processen zoals beschreven in de Project Start Architectuur middels: Algemene uitgangspunten / hoofdrequirements Beschrijving van gebruikersgroepen Functionele beschrijving van de drie datapackages Use Cases vanuit het gebruikersperspectief Hoofdfuncties van de gewenste API s (application programming interfaces). 1.5 Afbakening (scope) FO Het Functioneel ontwerp richt zich op de processen (blokken met pijlen naar rechts) afkomstig uit de Project start Architectuur. Het ontwerpen van een API valt buiten scope van dit FO. Datum / 106

9 Figuur 1: Processen (blokken met pijl) die tot de scope van het FO behoren. 1.6 Betrokken bij totstandkoming De inhoud van dit rapport is tot stand gekomen door literatuuronderzoek, interviews en workshops met een aantal direct betrokkenen in de keten. Naam Organisatie Rol Contact Erik Lubberink* BIJ12 Project owner Marlies Ellenbroek BIJ12 Programma manager Ivo Eggink* BIJ12 Informatiearchitect Peter van de Molen* BIJ12 Domein expert Tjeerd Wits Wits Consultancy Projectleider Marti Rijken Provincie projectleider Gelderland Monitoring Meinte Engelmoer Provincie Friesland Projectleider monitoring Dick Bal Min van EZ Domein expert Hennie Blikman Natuurmonumenten Adviseur Jan Holtland Staatsbosbeheer Adviseur Joost Buiks Rijkswaterstaat Adviseur Jaap Graveland Rijkswaterstaat Adviseur Piet Breemer Provincie Overijssel Adviseur Stephan Hennekens WUR / Alterra Manager Turboveg stephan.hennekens@wur.nl Erik van der Zee Geodan Lead architect Erik.van.der.zee@geodan.nl Peter van den Pol Geodan Domein architect Peter.van.den.pol@geodan.nl Nick Naus Geodan Consultant Nick.naus@geodan.nl Tabel 1 Overzicht van betrokken personen. 1.7 Aanpak Om tot een gedegen en gedragen functioneel ontwerp te komen is gebruik gemaakt van principes en uitgangspunten die zijn benoemd en toegelicht in de kaderstellende documenten (desk Datum / 106

10 research). Daarnaast zijn door middel van workshops en interviews de gebruikers typen en hun specifieke wensen en eisen ten aanzien van de CVD voorziening uitgewerkt. 1.8 Gehanteerde methodieken Bij de totstandkoming van dit FO is gebruik gemaakt van internationale standaarden en methoden voor functioneel ontwerp. Alle onderstaande standaarden en methoden worden fit for use toegepast, hetgeen inhoudt dat alleen relevante elementen worden toegepast in het project. Volère: Het specificeren van requirements wordt gedaan met het Volère framework Archimate: Modelleertaal voor architectuurmodellen UML: Unified Modeling Language is een standaard die wordt gebruikt om Use Cases en Use Case Diagrammen te ontwerpen EA: Enterprise Architect is de standaard voor het ontwerpen van vele UML diagrammen. EA kan gebruikt worden om schermontwerpen te realiseren in het project 1.9 Leeswijzer Hoofdstukindeling De hoofdstukindeling van het FO is als volgt opgebouwd. Hoofdstuk 1 Inleiding tot het document. Hoofdstuk 2 Overkoepelende requirements Hoofdstuk 3 Datapackages van de CVD Hoofdstuk 4 Gebruikers van de CVD Hoofdstuk 5 Applicatie interface structuur en flow Hoofdstuk 6 Use Cases Hoofdstuk 7 API Beschrijvingen Bijlagen Lijst van figuren Lijst met figuren die onderdeel vormen van dit functioneel ontwerp. Figuur 1: Processen (blokken met pijl) die tot de scope van het FO behoren Figuur 2: Introductie viewpoint van de gehele CVD Figuur 3: Overview gebruikersgroepen en CVD Figuur 4: Overzicht Packages Figuur 5: Voorbeeld XML uit een XML package Figuur 6: Voorbeeld zip bestand uit een desktoppackage Figuur 7 Gebruikers en System users Figuur 8: Overzicht gebruikers en rollen (bron: PSA CVD) Figuur 9: Overzicht gebruikers en hun rol in de CVD Figuur 10 Globale opbouw applicatie Figuur 11 Headerblok Figuur 12 Menublok Figuur 13 Functioneel blok zoeken Figuur 14 Schermvoorbeeld GPS Tour Figuur 15 Basiszoeken en raadplegen packages (gebaseerd op GPS Tour user interface) Datum / 106

11 Figuur 16 Footerblok Figuur 17 Applicatie Flow Diagram Figuur 18 Plot Use Cases op Applicatie Componenten GUIs en APIs Lijst van tabellen Lijst met tabellen die onderdeel vormen van dit functioneel ontwerp. Tabel 1 Overzicht van betrokken personen Tabel 2 Kaderstellende documenten voor het FO Tabel 3 Overzicht use cases Datum / 106

12 2 Overkoepelende requirements 2.1 Introductie van de CVD Waarom een CVD? Sinds de start van het Subsidiestelsel Natuur-en Landschap (SNL) in 2010 is, onder leiding van de gezamenlijke provincies, een keten ontwikkeld van organisaties die samenwerken op het gebied van informatievoorziening voor natuur: de Digitale Keten Natuur (DKN). Deze DKN heeft zich versterkt nadat er decentralisatieafspraken afspraken zijn gemaakt over de coördinerende rol van BIJ12 op het gebied van natuurinformatie. Dit rapport gaat in op ketensamenwerking op het vlak van vegetatie-, habitat-, en structuur data. Binnen deze DKN zijn vegetatie-, habitat-, en structuur data een onmisbare schakel (in interviews ook de motor genoemd) bij de monitoring van natuurgebieden conform de SNL methodiek, binnen Natura2000 ten behoeve van het opstellen van natuurbeheerplannen en bij de uitvoering van de PAS (Programmatische Aanpak Stikstof). Een goede betrouwbaarheid, bruikbaarheid en beschikbaarheid van de data zijn daarbij bepalend voor een goede uitvoering van deze processen. Data wordt in de huidige situatie op diverse plaatsen op diverse wijzen opgeslagen. Voor habitattypenkaarten is er een tijdelijke centrale voorziening, maar deze is specifiek gericht op het gebruik binnen AERIUS en voldoet maar beperkt aan de gewenste functionaliteit. De belangrijkste aanvullende behoefte is de opslag van alle huidige en historische versies van Habitattypenkaarten. Ook is er behoefte aan betere beschikbaarheid en doorzoekbaarheid van alle datasets. Veel versies worden nu nog decentraal bij de bronhouder opgeslagen in meerdere formaten. Conclusie: Aerius voorziet in een deel van de functionaliteit gericht op de werking van het rekeninstrumenten. Verder is er nu nog sprake van versnipperde informatie en deze informatie is onvoldoende gestandaardiseerd. Een centrale- of netwerkregistratie in de vorm van een Centrale Vegetatie Databank zou daar in moeten voorzien. Doelstelling van de Centrale Vegetatie Databank (CVD) is dat gegevens over vegetatie, habitattypen en structuur beter, eenduidiger en met een duidelijker kwaliteitslabel beschikbaar komen binnen de Digitale Keten Natuur. Voor aanleverende organisaties wordt het eenvoudiger om data al bij de bron gestructureerd in te winnen, valideren en bruikbaar op te leveren. Voor afnemende organisaties en systemen zullen gegevens goed vindbaar, bruikbaar en met kwaliteitslabel beschikbaar komen. Ook de toekomstvastheid wordt geborgd. De CVD wordt hiermee een onmisbare schakel in de Digitale Keten Natuur Wat is de CVD Deze CVD is een centrale datavoorziening (registratie) en voorziet in de kern in een toekomst vaste en gestructureerde opslag. Direct daar omheen biedt de CVD gestandaardiseerde aansluitingen (interfaces) naar toeleverende en afnemende ketensystemen. In de gehele lijn van aanleveren, opslag en gebruik voorziet de CVD in strikte validatie en is er functionaliteit die het mogelijk maakt kwaliteitskenmerken toe te kennen aan datasets. De aanlevering en afnemen van data verloopt via het concept van Datapackages (hoofdstuk 3). Voor zowel vegetatiekarteringen, habitattypenkarteringen als structuurkarteringen zijn datapackages gedefinieerd op basis van IMNa. Bronhouders wordt gevraag data aan te leveren volgens deze packages zodat deze voor de keten ook gestructureerd vindbaar, doorzoekbaar en bruikbaar zijn. Datum / 106

13 Onderstaande figuur beschrijft de procesflow van een datapackages in relatie tot de CVD. De tekst geeft een gesimplificeerde weergave van de requirements en het nadere ontwerp in dit document. 1. Aan de linkerzijde staan drie triggers voor de CVD, wijzigingen van een van de drie karteringen. 2. Er wordt vanuit gegaan dan de bronhouder in het eigen Natuur Management systeem op welke wijze dan ook een datapackage aanmaakt. Dat kan bijvoorbeeld CMSi zijn, maar ook Turboveg of een Gis pakket. Als het maar aan de standaard van IMNa voldoet. 3. Binnen de Scope van CVD zal een gebruiker met de rol Invoerder de packages in de CVD plaatsen. Technisch gezien is dat handmatig via een website, dan wel direct via een API. 4. Daarop volgt een Validatie door de validator op de structuur van de Package en op de waarschijnlijkheid dat een onderliggende soort daar ook feitelijk voor komt. 5. De rol kwaliteitsbeheerder heeft de middelen om een oordeel en beschrijving van dat oordeel toe te voegen over de kwaliteit van de totale package. 6. Een raadpleger heeft daarop alle mogelijkheden om de CVD te doorzoeken en packages te downloaden of globaal in te zien. Zoeken en downloaden kan ook direct via de API. 7. Om de validaties strikt uit te kunnen voeren en uniformiteit te kunnen garanderen is er een rol catalogi beheerder die zorgt dat er een waarheid van codes, (vegetatie) typen bestaat. Figuur 2: Vereenvoudigde procesflow en rollen rondom de CVD dienst Datum / 106

14 Een meer complete uitgebreide plaat (bron PSA) wordt hieronder weergegeven. Hier is ook de infomatie en technologie laag weergegeven. Figuur 3: Introductie viewpoint van de gehele CVD. Van links naar rechts: Rollen, Processen, De CDV met Functies en aan de rechterzijde potentiële herbruikbare componenten. Datum / 106

15 2.1.3 Kaderstellende documenten De onderstaande kaderstellende documenten voor dit FO zijn vastgesteld door de projectgroep. Nr Titel Motivatie 1 Offerteaanvraag Functioneel Ontwerp Bepaalt doestelling en scope 2 Project Start Architectuur CVD Dit document bevat de architectuur uitgangspunten en kaders voor verder ontwerp en realisatie van de CVD voorziening. Biedt kaders en uitgangspunten voor zowel functionele-, data- en niet-functionele requirements 3 Werkwijze Monitoring en Beoordeling Natuurnetwerk en Natura 2000/PAS 4 Monitoring en Informatievoorziening Natuurrapportages Kader: van IST naar SOLL met AFSPRAKEN Geeft inzicht in de positie van de centrale vegetatiedatabank binnen de digitale keten natuur Geeft inzicht in systemen die binnen de digitale keten natuur worden gebruikt en welk zullen interacteren met de centrale vegetatiedatabank 5 Informatiemodel Natuur (IMNA) Geeft richting aan de te hanteren definities 6 Vegetatiekarteringsprotocol Als basis voor IMNa en de inhoud van de packages. Tabel 2 Kaderstellende documenten voor het FO 2.2 Requirements CVD Overview gebruikersgroepen en CVD De CVD kent een aantal gebruikersgroepen die een of meerdere relaties (rollen) tot de CVD hebben. Onderstaand overzicht toont een aantal belangrijke gebruikersgroepen die symbool staan van alle gebruikers van de CVD. Voor meer informatie over de gebruikers groepen wordt verwezen naar hoofdstuk 4. In de basis hebben gebruikers een directe relatie via een website (WebFrontend) of via de eigen applicatie direct op de technische interface (API). Via deze interfaces kunnen zij packages valideren, importeren, zoeken en raadplegen. Daarnaast kent de CVD aparte rollen voor catalogi beheer, kwaliteitsbeheer en systeembeheer. Datum / 106

16 Figuur 4: Overview gebruikersgroepen en CVD Overall requirements Alle functionele requirements zijn verwerkt bij bijbehorende use cases (zie hoofdstuk 6). Nr Categorie Requirement Toelichting A1 Focus op Data De CVD is een data registratie. De focus ligt op data (invoer, opslag, uitvoer). De functionaliteit van de CVD wordt daartoe beperkt - Importen en Exporten van dataverzamelingen - Beheer van dataverzamelingen in de voorziening (o.a. inhoud toevoegen en kwaliteitslabel toevoegen) - Rapportage is beperkt tot overzichten van de status van de voorziening (CVD statistieken) - Systeem- en userbeheer A2 Data centralisatie Alle relevante vegetatiedata op één plek bij elkaar De Centrale Vegetatie Databank heeft als registratie een breed toepassingsgebied waarbij kwaliteit van data cruciaal is. Typerend voor de CVD is dat dataverzamelingen vooral waarde hebben als de data bijeen worden gehouden. Een voorbeeld is dat het landelijk vegetatietype vooral van waarde is wanneer ook het lokale type, de kaarten en de metadata over inwinning worden vastgelegd. Het verdient daarom de voorkeur om binnen de CVD alle relevante vegetatiedata op één plek bij elkaar op te slaan. A3 Packages Gebruik van Packages Het principe van het gebruik van packages, naar analogie van Digitale Ruimtelijke Plannen, past goed bij het type datasets van de CVD. Vegetatie- en habitatinventarisaties zijn duidelijk gekoppeld aan een gebied op een bepaald Datum / 106

17 tijdstip (ruimte+tijd). Iedere inventarisatie leidt tot een aantal logisch bij elkaar horende informatieproducten (o.a. kaart, toelichtingen, metadata) A4 Datamodel Generiek kerndatamodel en flexibele invoer en uitvoer standaarden (Flexibiliteit / wendbaarheid) A5 Kwaliteit Toekennen kwaliteitslabel aan dataverzameling Om goed in te spelen op de benodigde flexibiliteit zal gebruik moeten worden gemaakt van een generiek datamodel. Het is onduidelijk en te duur om bij iedere wijziging van de standaard de kerndatastructuur in de voorziening aan te passen. Dataverzamelingen (data packages) kunnen binnen de CVD worden gelabeld met een kwaliteitskenmerk, waardoor de eindgebruiker beter waarde kan hechten aan de bron. A6 Validatie Valideren van Packages De data in de CVD voorziening is technisch gevalideerd en daarmee in hoge mate betrouwbaar (geen vegetatietypen die niet bestaan en technisch bruikbaar voor afnemende systemen). A7 Catalogi Gebruik van externe catalogi Goed beheerbare ondersteunde catalogi en codelijsten waarin alle referenties zoals habitattypen, vegetatietypen en soorten gestructureerd zijn vastgelegd. De lijsten staan bij voorkeur los van de dataopslag en zijn goed in te zien via een website en geautomatiseerd uit te lezen via bijvoorbeeld een gedocumenteerde API. Een voorbeeld is codes.ndff.nl of de EUNIS website habitats. De benodigde catalogi en taxonomieën zijn beschikbaar voor de gehele keten. A8 Catalogi Hergebruik van bestaande externe catalogi Zoveel mogelijk gebruik maken van al bestaande externe catalogi zoals de lijst met Nederlandse habittypen (beheerder: ministerie EZ). Voorwaarde is wel dat deze catalogi bij voorkeur los van de dataopslag staan, goed zijn in te zien via een website en geautomatiseerd uit te lezen zijn via bijvoorbeeld een gedocumenteerde API. A9 Interfaces Standaard Koppelvlakken Via koppelvlakken kunnen monitoringtools, validatietools, rekentools en rapportage tools inprikken op de voorziening om (packages) te brengen en te halen. Er is een open (technische) standaard voor het uitwisselen voor vegetatie-, habitat-, en structuur data. A10 Hergebruik Hergebruik van basisblokken Hergebruik van architectuur basisblokken componenten waar mogelijk (bv. PGR, PDOK) Datum / 106

18 A11 Kaarten Landelijke kaartbeelden Naast Packages zal de CVD jaarlijks of halfjaarlijks de data beschikbaar stellen voor het aanmaken van landelijk kaartbeelden voor praktisch gebruik van de landsdekkende data. Voorbeelden van toepassingen zijn vergunningverlening PAS en leefgebiedsanalyse van de PAS. De CVD moet de mogelijkheid bieden om de, voor deze landelijke kaartbeelden benodigde, gegevens te exporteren zodat een inhoudelijke expert de landelijke kaartbeelden kan produceren. De landelijke kaartbeelden worden vervolgens gepubliceerd in al al bestaande applicaties (zie A10) A12 Interfaces API en package beheer Er zullen zowel wijzigingen plaatsvinden in de interfacedefinitie als de packages. Al is het maar om ook histoische data in de CVD te kunnen laden. Het is van belang de CVD meerder versies van API s en packages kan ondersteunen. Het is van belang dat bij het inlezen van de package ook de gebruikte API en packageversie wordt vastgelegd. A13 Browserondersteuning De CVD webapplicatie is te gebruiken met verschillende webbrowsers De CVD is minimaal te gebruiken met recentie versie van de volgende webbrowsers: - Mozilla Firefox - Google Chrome - Internet Explorer Data requirements Nr Categorie Requirement Nadere toelichting D1 DataPackages De CVD wordt gevoed door DataPackages. Alleen datapackages zijn input voor de CVD D2 Drie inhoudelijke packages De CVD leest drie packages: VegetatieKarteringPackages, HabitattypenPackages en StructuurKarteringPackages D3 Type Packages Er zijn twee type packages: een XML package voor Machine to Machine communicatie en een DesktopPackage voor direct gebruik in standaard desktopapplicaties Zie ook paragraaf 3.1 D4 Kwaliteit data Kwaliteiteisen staan beschreven in IMNa. Informatiemodel Natuur D5 Kwaliteit Packages De kwaliteit van de package als totaal wordt beschreven op Packageniveau. Dat is feitelijk de metadata van de package D6 Toekennen kwaliteit De CVD moet het toekennen van kwaliteit op drie niveaus ondersteunen. 1. Bronhouder: De organisatie die de package uploadt 2. Opdrachtgever: De opdrachtgever voor de package (vaak gelijk aan bronhouder) Datum / 106

19 3. Autoriteit: Persoon of instantie die onafhankelijk een kwaliteitslabel toekent. Voor HabitattypenPackages is dat ministerie van Economische Zaken (EZ). Voor Vegetatie is dat nog niet ingericht. D7 Data historie Packages gaan altijd over een vaste periode (begindatum / einddatum) en zijn meestal gebaseerd op het veldonderzoek. Eenmaal in de CVD blijft de package in de CVD; deze blijft altijd zijn waarde houden. D8 Updaten / vervangen van packages Data packages kunnen alleen als geheel worden vervangen D9 Versies Alleen bij Habitattypenpackages worden versies ondersteund. D10 Gevoelige data De CVD moet gevoelige data kunnen uitsluiten voor niet geautoriseerde gebruikers. Hier wordt de lijn van de NDFF gevolgd als het gaat om een selectie van soorten die gevoelig zijn. De systematiek moet verder eenvoudig zijn: - Wanneer haalbaar, alles data open - Alternatief: 2 niveaus voor het hele systeem voor alle packages: (a) recht op het inzien van alle data of (b) recht op het inzien nietgevoelige data. Reden is om de samenhang van de data te borgen. De bronhouder is verantwoordelijk voor de package. Vanwege formele vaststellingsprocedure. Het gaat hierbij om kwetsbare soorten die gevoelig zijn voor uitscheppen. D11 Open data Data is in principe voor ieder toegankelijk. Maar mogelijk beperkt volgens requirement D10 D12 Coordinaat systeem Geodata wordt opgeslagen in het Rijksdriehoek stelsel (EPSG 28992). D13 Database Opslag van data in een spatial database / DMS D14 Gebruik basisregistraties Top10NL en luchtfoto s worden als visuele referentiekaartlagen ingezet, niet om de ligging van data te valideren. D15 Datavalidatie Data wordt gevalideerd op structuur Alleen packages aangeleverd volgens een afgesproken structuur worden opgenomen in de CVD. De structuur is afgeleid van het IMNa productmodel vegetatie en habitats D16 Datavalidatie Data wordt gevalideerd op codelijsten Voor enkele attributen van de packages mogen alleen waarden uit codelijsten gebruikt worden. De CVD controleert hierop (bijvoorbeeld: bestaat een Datum / 106

20 landelijk vegetatietype in de VVN lijst?) D17 Datavalidatie Data wordt gevalideerd op topologie De CVD controleert of aan dee topologieregels zoals beschreven in IMNa voldaan is. D18 Datavalidatie Package wordt technisch gecontroleerd De CVD controleert bijvoorbeeld of het juiste bestandsformaat is aangeleverd en of het bestand niet te groot is. De exacte controles worden gedurende het bouwtraject vastgesteld. D19 Soortvalidatie Soort waarschijnlijkheid wordt getoetst aan de NDFF validatieservice D20 Data Levensduur Vegetatiegegevens blijven na inwinning altijd waardevol, ook historisch ingewonnen gegevens. Informatie opgenomen in de CVD dient gearchiveerd te worden Koppelingen Nr Categorie Requirement Nadere toelichting K1 API Alle communicatie verloopt via de API. API s zijn duidelijk beschreven en bruikbaar. Communicatie mogelijk via REST, uitwisseling van XML/JSON K2 API Beschrijving API s zijn duidelijk beschreven en hebben een voorbeeld URL per functie. K2 Web Front-end Voor vrijwel alle functies (zie Use Cases) zijn ook User interfaces beschikbaar. Niet alle gebruikers hebben de beschikking over een Natuur Management systeem Voorkomen en stijl Nr Categorie Requirement Nadere toelichting V1 Voorkomen en stijl Het product moet voldoen aan de huisstijl van BIJ Gebruikersgemak en personalisatie Nr Categorie Requirement Nadere toelichting G1 Gebruikersgemak Gebruiksvriendelijke en ergonomische interface. De gebruiker moet weten of hij is ingelogd en welke packages hij kan beheren. Zie ook webrichtlijnen voor meer richtlijnen over gebruikersvriendelijkheid. Datum / 106

21 G2 Help De applicatie dient voorzien te zijn van een eenvoudige helpfunctie G3 Personalisatie De site moet rekening houden met persoonlijke instellingen van een gebruiker. Deze zijn gekoppeld aan het gebruikers account en-rol G4 Taal De site zal in de Nederlandse taal beschikbaar worden gesteld G5 Benodigde training De applicatie moet door gebruikers bediend kunnen worden zonder aanvullende training G6 Begrijpelijkheid en beleefdheid Vaktaal, begrippen en termen worden in de site uitgelegd via korte toelichtingen die zichtbaar worden wanneer men met de muis over een gemarkeerd begrip hoovert G7 Toegankelijkheid Het product moet zoveel mogelijk voldoen aan webrichtlijnen voor overheidstoepassingen Performance Nr Categorie Requirement Nadere toelichting P1 Snelheid De reactietijd van de website moet binnen acceptabele grenzen liggen (response binnen 2 seconden in 90% van de gevallen, en nooit meer dan 5 seconden) P2 Betrouwbaarheid Het systeem heeft een uptime van 98% en beschikbaarheid P3 Capaciteit Het system moet 30 (inschatting vanuit interviews) gelijktijdige gebruikers kunnen bedienen tussen kantooruren. Buiten deze uren moet het systeem 10 gelijktijdige gebruikers aankunnen P4 P5 Schaalbaarheid en uitbreidbaarheid Systeem levensduur Het systeem moet eenvoudig uitbreidbaar en schaalbaar zijn via API Beheer en nieuwe versies van Packages De applicatie heeft een levensduur van maximaal 10 jaar Onderhoud en Ondersteuning Nr Categorie Requirement Nadere toelichting O1 Service niveau Basis SLA serviceniveau De verwachting is dat een standaard serviceniveau van beschikbaarheid tijdens kantooruren en oplostijden Datum / 106

22 o.b.v. best effort voldoende is O2 Support Gebruikers hebben de beschikbaarheid over specialistische hulp via de BIJ12 helpdesk O3 API Beheer De API is uitbreidbaar en backwards compatible O4 Overige Zie verder de beheerrequirements in de PSA Het aantal directe gebruikers is beperkt. Verschillende versies van de API worden ondersteund zodat stakeholders tijd hebben om hun interface aan te passen aan een nieuwe versie van de API Veiligheid (security) Nr Categorie Requirement Nadere toelichting S1 Backup Reguliere backup eens per dag zou voldoende moeten zijn voor de CVD. Het aantal dagelijkse transacties is beperkt. De kans dat de bronhouder niet meer beschikt over de brondata is nihil. S2 Vastleggen formele versies Hoewel de CVD bij het vervangen van packages de oude versie niet beschikbaar houdt, is het wel wenselijk dat er geen data wordt verwijderd. Feitelijk wordt er dus alsnog een formelehistorie (NEN3610) vastgelegd, maar deze is niet direct voor de gebruiker beschikbaar. S3 Toegang De site is alleen toegankelijk voor organisaties in de keten. Authenticatie vindt plaats op basis van username en password S4 Toegang Autorisatie wordt uitgevoerd door beheerder van de site. S5 Toegang Packages worden per bronhouder geregistreerd. Alleen de bronhouder is geautoriseerd om zijn eigen packages te updaten/verwijderen. S6 Gevoelige data Gevoelige data confrom rode lijst Zie ook data requirements S7 Integriteit Het systeem dient foutieve invoer en SQL insertion te voorkomen. S8 Privacy Het systeem beschermt persoonlijke gegevens van gebruikers conform wetgeving (bescherming persoonsgegevens) Zie ook validatie bij data requirements Juridisch Nr Categorie Requirement Nadere toelichting J1 Waarmerken Habitattypenpackages dienen te worden Zie ook data requirements. gewaarmerkt. Datum / 106

23 Detaillering requirements Meer specifieke requirements vanuit gebruikersperspectief worden beschreven bij de Use Case in hoofdstuk 6. Datum / 106

24 3 Datapackages van de CVD 3.1 Wat zijn DataPackages? Het principe van het gebruik van packages, naar analogie van Digitale Ruimtelijke Plannen, past goed bij het type datasets van de CVD. Vegetatie- en habitatinventarisaties zijn duidelijk gekoppeld aan een gebied op een bepaald tijdstip (ruimte+tijd). Iedere inventarisatie leidt tot een aantal logisch bij elkaar horende informatieproducten (o.a. kaart, toelichtingen, metadata). Belangrijkste motivaties voor het gebruik van packages: Een vegetatiekartering, habitattypenkartering en een structuurkartering bestaan uit een verzameling bij elkaar horende informatieproducten zoals kaarten, toelichtingen en metadata. Een package kan er in voorzien deze data ook technische bij elkaar te houden De onderdelen van een package hebben in samenhang meer waarde dan los van elkaar. Een package borgt deze samenhang Een package bevat metadata over alle informatieproducten heen Aan de gehele package kan een kwaliteitslabel worden toegekend HabitattypenPackages worden als geheel formeel vastgesteld door het bevoegd gezag. Op packageniveau kan de data als geheel worden gelabeld (als vastgesteld) en gewaarmerkt bij de notaris (door middel van hashwaarden ) In veel gevallen wordt data in een package door één karteringsbureau uitgevoerd 3.2 Type packages Binnen de scope van de CVD worden drie packages onderscheiden: VegetatiekarteringsPackage: dit package bevat alle data rondom een gestructureerd vastgelegde vegetatiekartering, bestaande onder meer uit metadata, landelijk-en lokale typeringen en vegetatieopnamen. HabitattypenPackage: dit package bevat alle data rondom een gestructureerd vastgelegde habitatkartering, bestaande uit onder meer metadata, waarmerkgegevens en eventueel aanvullende onderbouwing met een landelijke vegetatietypering. StructuurkarteringsPackage: dit package bevat alle data rondom een gestructureerd vastgelegde structuurkartering, bestaande uit onder meer metadata, een structuurclassificatie met bijbehorende percentages van structuurelementen. Datum / 106

25 Figuur 5: Overzicht Packages. De landelijke en catalogi packages worden wel getoond, maar niet verder als package uitgewerkt. Voor meer informatie wordt verwezen naar het informatiemodel Natuur (IMNa) productmodel Vegetatie en Habitats. 3.3 Packages inhoudelijk (bron IMNa) VegetatieKarteringPackage Het VegetatieKarteringPackage is bedoeld voor het uitwisselen van vegetatiegegevens. De eindgebruikers zijn aanleverende terreinbeheerders zoals Natuurmonumenten, Staatsbosbeheer, Rijkswaterstaat, Defensie en afnemende organisatie zoals provincies, onderzoeksinstituten, rijk en dezelfde terreinbeheerders. Een vegetatiekarteringpackage is een gebundelde set van samenhangende gegevens over vegetatie die binnen een door tijd en ruimte afgebakende onderzoeksopdracht worden verzameld en geanalyseerd. Deze package bevat gegevens die in het werkveld ook vegetatiekaart of Datum / 106

26 vegetatiekartering wordt genoemd. Figuur 6: Conceptueel model VegetatieKartingPackage Datum / 106

27 HabitatTypePackage Een HabitatTypePackage is bedoeld om Habitatkaarten gestructureerd uit te wisselen. Directe gebruikers zijn de voortouwnemers (of diens opdrachtnemers) en provincies, groene vergunningenverleners, maar ook afnemende systemen zoals het rekeninstrument Aerius. Een habitattypepackage is een gebundelde set van samenhangende gegevens over habitat die binnen een door tijd en ruimte afgebakende onderzoeksopdracht worden verzameld en geanalyseerd. Deze package bevat gegevens die in het werkveld ook habitattypenkaart of habitkartering wordt genoemd. Figuur 7: Conceptueel model Habitatpackage StructuurKarteringPackage Een StructuurKarteringPackage is bedoeld om Structuurkaarten gestructureerd uit te wisselen. Structuurkaarten worden onder andere gebruikt voor het bepalen van de natuurkwaliteit in het kader van SNL. Structuurobjecten beschrijven de structuur over meerdere vegetatievlakken heen en zijn daarom opgenomen in een aparte package. Een structuurkarteringpackage is een gebundelde set van samenhangende gegevens over structuur die binnen een door tijd en ruimte afgebakende onderzoeksopdracht worden verzameld. Deze package bevat gegevens die in het werkveld ook structuurkartering wordt genoemd. Datum / 106

28 Figuur 8: Conceptueel model StructuurKarteringPackage 3.4 Implementatie packages in uitwisselstandaarden Er zijn drie type packages: een XML package voor Machine to Machine communicatie, een DesktopPackage voor direct gebruik in standaard desktopapplicaties en een LegacyPackage voor niet gestandaardiseerde data XML Package De XML package is primair bedoeld voor machine tot machine communicatie. Feitelijk bestaat de package uit een ZIP-bestand, met daarin één XML-bestand met een aantal PDF bestanden. In onderstaande figuur wordt een voorbeeld gegeven waarin de IMNa klassen terug te vinden zijn. Figuur 9: Voorbeeld XML uit een XML package ten behoeve van machine to machine communicatie Desktop Package De desktoppackage is gebaseerd op een ZIP bestand. Hierin worden dezelfde gegevens vastgelegd als in de XML package, maar in bestandformaten die leesbaar zijn in standaard desktop applicaties zoals ArcGIS, Quantum GIS of een Acrobat PDF reader (Zie Figuur 10). In onderstaande figuur is een file GeoDatabase opgenomen als voorbeeld, omdat provincies veel gebruik maken van ESRI software. Datum / 106

29 De CVD kan alleen XML packages inlezen, een desktop package dient dus omgezet te worden naar een XML package. Er kunnen verschillende conversie tools nodig zijn voor de verschillende bronhouders. Figuur 10: Voorbeeld zipbestand uit een desktoppackage Legacy Package De CVD is een voorziening die zich richt op het beschikbaar stellen van goed gestructureerde data. Er is echter nog veel oude data die vooral voor onderzoek voor altijd waardevol blijft. Dit is data die alleen in een (gescand) rapport beschikbaar is. Om ook deze data toch toegankelijk te maken, biedt de CVD de mogelijkheid om ook oude rapporten in de CVD te plaatsen. De gebruiker is dan alleen verplicht de metadata (PackageMetadata) in te vullen via de website. Voor dit type data wordt wereldwijd de term legacy data 1 gehanteerd. Om die reden is de naam van de Package Legacy Package. 1 Volgens business dictionary: Information stored in an old or obsolete format or computer system that is, therefore, difficult to access or process. Datum / 106

30 4 Gebruikers van de CVD Dit hoofdstuk geeft een overzicht en een uitvoerige omschrijving van de verschillende eindgebruikers van de CVD. Paragraaf 4.1 beschrijft de verschillende typen gebruikers die onderkend worden, in paragraaf 4.2 worden de gebruikers op organisatieniveau en hun rol binnen het systeem beschreven. Paragraaf 4.3 geeft een gedetaileerde omschrijving van de persona s; de daadwerkelijke gebruikers van de CVD die werkzaam zijn binnen de organisaties genoemd in paragraaf Typen gebruikers Er zijn twee typen gebruikers die interacteren met het CVD systeem: 1. Eindgebruikers ( human users ) a. CVD-Gebruiker die rechtstreeks met het CVD systeem interacteren via de Grafische User Interface ( website ) van het systeem b. Extern-systeemgebruiker maakt via GUI van extern systeem indirect gebruik van het CVD systeem 2. Externe systemen ( external system users ): systemen die met het CVD systeem interacteren via de Application Programming Interfaces (APIs) van de CVD ( machine-tomachine communication ) Figuur 11 geeft een overzicht van de twee typen gebruikers en de verschillende wijzen dat ze interacteren met het CVD systeem; direct via een GUI of indirect via een extern systeem. CVD GUI Extern Systeem GUI Extern Systeem API Extern Systeem CVD API CVD Systeem Figuur 11 Gebruikers en System users Datum / 106

31 4.2 Overzicht gebruikers De toekomstige gebruikers van de applicatie zijn hieronder in Figuur 12 weergegeven op organisatieniveau. In Figuur 12 zijn behalve de gebruikers ook hun rol(len) binnen de CVD weergegeven. In de figuur eronder worden de gebruikers en hun rol verder in detail beschreven. Beide figuren zijn afkomstig uit de PSA van de CVD, maar ter volledigheid ook in het FO opgenomen. Figuur 12: Overzicht gebruikers en rollen (bron: PSA CVD) Gebruiker (Rol) + Betrokkenheid BIJ12 (Eigenaar) De CVD voorziening is eigendom van BIJ12 vanuit haar rol in de digitale keten natuur. (Kwaliteitsbeheerder) Het heeft de voorkeur om het toekennen van kwaliteit door een onafhankelijke organisatie of instantie toe te laten kennen. In deze PSA is uitgegaan van een rol voor BIJ12, aangezien zij zelf geen producent van vegetatie- of habitattypengegevens is. Dat wil zeggen dat BIJ12 een Datum / 106

32 Gebruiker (Rol) + Betrokkenheid kwaliteitslabel toekend aan iedere dataverzameling in de CVD of in ieder geval dit proces faciliteert. Het is echter mogelijk dat een andere organisatie (bijvoorbeeld EZ of een individuele provincie het label toekend voor habitattypen gegevens). N.B. De procesafspraken en de organisatie rondom kwaliteitsbepaling dient nog nader uitgewerkt te worden. (Systeembeheerder) CVD voorziening wordt op functioneel niveau beheerd door BIJ12. De kans is aanzienlijk dat voor een deel van de CVD het (technisch) applicatiebeheer wordt ondergebracht bij BIJ12 unit GBO Provincies. Deze PSA doet daar verder geen uitspraken over. In het hoofdstuk transitie wordt wel een match gemaakt met aanwezige bouwblokken die aanwezig zijn bij BIJ12/GBO. De rol (systeemeigenaar) is in deze PSA niet expliciet benoemd. Naar analogie met de SNL applicatie zou dat de AACVP zijn. Europa (Raadpleger) (indirect) van data uit CVD voor EU rapportages. Habitattypenkaarten zijn INSPIRE-plichtig wat inhoudt dat een landelijke set van habitatdata conform INSPIRE specificaties aangeleverd dient te worden door ieder Europese lidstaat. Groene Adviesbureaus en PGO s Onderzoeksinstituten (Raadpleger) gebruiken vegetatie-en habitatdata voor het uitvoeren van onder andere milieueffectrapportages en vergunningaanvragen voorbereiden. (Raadpleger) gebruiken vegetatie-en habitatdata voor uiteenlopende onderzoeksdoeleinden zoals voor het uitvoeren van trendanalyses van natuurkwaliteit en het evalueren van het effect van beheerstrategieën in natuurgebieden. Opsteller van EU rapportages zoals VHR (WOt-IN). Provincies (Invoerder) invoeren vegetatie en habitatdata in CVD (Raadpleger) vegetatiedata gebruikt om uitspraken te doen over de kwaliteitsaspecten: habitattype kwaliteit, natuurkwaliteit SNL, milieu- en watercondities, structuurkenmerken. (Raadpleger) Opsteller van rapportages natuurkwaliteit (PAS, VRN etc.) Rijk (EZ + IenM) (Kwaliteitsbeheerder) beoordelen kwaliteit CVD data. (Raadpleger) raadplegen van vegetatie en habitat informatie. Rijkswaterstaat (Invoerder) invoeren vegetatie en habitatdata in CVD. (Raadpleger) vegetatiedata gebruikt om uitspraken te doen over de kwaliteitsaspecten: habitattype kwaliteit, natuurkwaliteit SNL, milieu- en watercondities, structuurkenmerken. Datum / 106

33 Gebruiker (Rol) + Betrokkenheid (Raadpleger) Opsteller van rapportages natuurkwaliteit (PAS, VRN etc.) TBO s (Invoerder) vegetatie en habitatdata in CVD. (Raadpleger) gebruiken vegetatie-en habitatdata voor het monitoren van natuurkwaliteit ten behoeve van SNL en Natura 2000/ PAS en voor het evalueren en bijstellen van beheerplannen. Waterschappen (Invoerder) invoeren vegetatie en habitatdata in CVD Publiek ( alle partijen ) Figuur 13: Overzicht gebruikers en hun rol in de CVD (Raadpleger) gebruiken vegetatie-en habitatdata onder andere om uitspraken te doen over de kwaliteitsaspecten: milieu- en watercondities, structuurkenmerken en in mindere mate flora en fauna. Ook voor het opstellen van groenbeheerplannen worden deze data gebruikt. (Validator) validatie functies zijn publiek en daarmee voor iedereen beschikbaar. (Raadpleger) raadplegen van vegetatie en habitat informatie. 4.3 Detaillering gebruikers In de volgende paragrafen zijn de volgende gebruikers verder in detail uitgewerkt: - Medewerker TBO met natuurmanagementsysteem - Medewerker TBO zonder natuurmanagementsysteem - Medewerker ecologie Rijkswaterstaat - Beleidsmedewerker natuur provincie - Medewerker groenbureau - Beleidsmedewerker ministerie van Economische Zaken - Medewerker onderzoeksinstituut / onderwijsinstelling Voor iedere gebruiker zijn de volgende aspecten beschreven: - Kennis van het onderwerp - Motivatie voor een CVD - Ervaring met technologie - Benodigde functionaliteiten - Catalogibeheer - Kwaliteitslabel - Use cases van toepassing op de gebruiker Onderstaande informatie is verzameld gedurende in het project afgenomen interviews. Datum / 106

34 4.3.1 Medewerker TBO met natuurmanagementsysteem Natuurmonumenten, Staatsbosbeheer en enkele provinciale landschappen maken beide gebruik van het systeem CMSi. Andere TBO s gebruiken het systeem CRS2 voor hun dagelijks terreinbeheer. Meerdere organisaties gebruiken ook Turboveg voor het opslaan van vegetatieopnamen. In ieder geval CMSi en TurboVeg gaan in bepaalde mate aansluiten op de API van de CVD (bron: interviews). Medewerker TBO met natuurmanagementsysteem Kennis van het onderwerp Een medewerker van een TBO met een natuurmanagementsysteem is actief als boswachter, ecoloog, projectmedewerker of beheerteammedewerker. Deze medewerkers werken vaak met vegetatie-en of habitattypekaarten, kunnen deze interpreteren, beoordelen en gebruiken in hun dagelijkse werkzaamheden. Bovendien zijn zij gewend te werken met natuurmanagementsystemen zoals CMSi. Motivatie - Alle vegetatie-en habitattypekaarten op één plek in de CVD. Momenteel kost het veel tijd om alle gegevens te verzamelen bij verschillende partijen. - Alle vegetatie-en habitattypekaarten uniform (met dezelfde structuur) opgeslagen. Dit scheelt veel werk bij het samenvoegen, vergelijken en analyseren van de gegevens. - Het wordt makkelijker om beheeranalyses uit te voeren als ook informatie van andere beheerders beschikbaar komt. - Voorkomen van dubbel karteringen Ervaring met technologie Benodigde functionaliteiten De medewerker TBO is gewend om te werken met het natuurmanagementsysteem. Vanuit dit systeem wil hij/zij dan ook nieuwe packages aanleveren aan de CVD en packages uit de CVD halen. Belangrijke functionaliteiten van de CVD zijn: - Zoeken op vegetatietype - Zoeken op datum - Zoeken op naam van de kartering - Zoeken op karteringen in een bepaald gebied - Kunnen raadplegen van metadata van de package. Vooral het kunnen nagaan van de kwaliteit van de package is belangrijk (welke validaties zijn uitgevoerd en is de handmatige controle uitgevoerd?) - Controleren van de vertaling lokale naar landelijke vegetatietypes. Catalogibeheer - De medewerker TBO vindt het belangrijk dat de gebruikte catalogi centraal beheerd worden zodat alle partijen dezelfde waarden en catalogi gebruiken. Datum / 106

35 - Deze catalogi kunnen ook wijzigen, daarom is het nodig om ook de versie van de gebruikte codelijsten in de packages op te kunnen vragen. - Inhoudelijke experts beheren de catalogi, een stuurgroep geeft sturing. Kwaliteitslabel - Inhoudelijke experts bepaalt het kwaliteitslabel, zeker voor natura2000 habitatypen - Per package is na te gaan wat het kwaliteitslabel is. - Zowel kwantitatieve als kwalitatieve beoordeling is gewenst. Use cases UC-Inl, UC-Acc, UC-CHS, UC-PC, UC-Val, UC-Lak, API-Upl, API-Zoe Medewerker TBO zonder natuurmanagementsysteem TBO s die niet gebruik maken van een natuurmanagementsysteem maken veel met Excel en/of GIS software. Deze groep gebruikers zal gebruik gaan maken van de GUI van de CVD. Medewerker TBO zonder natuurmanagementsysteem Kennis van het onderwerp Een medewerker van een TBO zonder natuurmanagementsysteem is actief als boswachter, ecoloog, projectmedewerker of beheerteammedewerker. Deze medewerkers werken vaak met vegetatie-en of habitattypekaarten, kunnen deze interpreteren, beoordelen en gebruiken in hun dagelijkse werkzaamheden. Zij werken met papieren kaarten, Excel en/of GIS software. Motivatie - Alle vegetatie-en habitattypekaarten op één plek in de CVD. Momenteel kost het veel tijd om alle gegevens te verzamelen bij verschillende partijen. - Alle vegetatie-en habitattypekaarten uniform (met dezelfde structuur) opgeslagen. Dit scheelt veel werk bij het samenvoegen, vergelijken en analyseren van de gegevens. - Het wordt makkelijker om beheeranalyses uit te voeren als ook informatie van andere beheerders beschikbaar komt. - Voorkomen van dubbel karteringen Ervaring met technologie Benodigde functionaliteiten De medewerker TBO is gewend om te werken met verschillende applicaties zoals Excel en GIS software. natuurmanagementsysteem. Deze gebruikers willen packages kunnen aanleveren en afnemen van de CVD met behulp van een overzichtelijke en gebruikersvriendelijke user interface zoals een website. Ook is het belangrijk dat de gegevens uit de CVD bekeken kunnen worden in hun eigen GIS of direct in de CVD. Belangrijke functionaliteiten van de CVD zijn: - Zoeken op vegetatietype - Zoeken op datum Datum / 106

36 - Zoeken op naam van de kartering - Zoeken op karteringen in een bepaald gebied - Kunnen raadplegen van metadata van de package. Vooral het kunnen nagaan van de kwaliteit van de package is belangrijk (welke validaties zijn uitgevoerd en is de handmatige controle uitgevoerd?) - Controleren van de vertaling lokale naar landelijke vegetatietypes. - Kunnen downloaden van packages in een formaat dat direct in een GIS gebruikt kan worden of direct in de CVD bekeken kan worden. Catalogibeheer - De medewerker TBO vindt het belangrijk dat de gebruikte catalogi centraal beheerd worden zodat alle partijen dezelfde waarden en catalogi gebruiken. - Deze catalogi kunnen ook wijzigen, daarom is het nodig om ook de versie van de gebruikte codelijsten in de packages op te kunnen vragen. - Inhoudelijke experts beheren de catalogi, een stuurgroep geeft sturing. Kwaliteitslabel - Inhoudelijke experts bepaalt het kwaliteitslabel, zeker voor natura2000 habitatypen - Per package is na te gaan wat het kwaliteitslabel is. - Zowel kwantitatieve als kwalitatieve beoordeling is gewenst. Use cases UC-Inl, UC-Acc, UC-CHS, UC-PC, UC-Val, UC-Lak, UC-My, UC-Zoe, UC-Vrij, UC-Imp, UC-Aan Medewerker ecologie RWS Medewerker ecologie RWS Kennis van het onderwerp Een medewerker ecologie (in de toekomst technisch adviseur ) van RWS houdt zich bezig met het beheren en uitbesteden van alle vegetatiekarteringen van de buitendijkse gebieden van RWS. RWS hanteert een eigen uitwisselformaat voor de vegetatiekarteringen met een eigen vegetatietypologie (SALT). Motivatie - Alle vegetatie-en habitattypekaarten op één plek in de CVD zodat BV Nederland deze gegevens kan bekijken en downloaden. - Alle vegetatie-en habitattypekaarten uniform (met dezelfde structuur) opgeslagen. Dit scheelt veel werk bij het samenvoegen, vergelijken en analyseren van de gegevens van andere partijen. Ervaring met technologie De medewerker ecologie is gewend om te werken met Excel en een GIS systeem. De CVD moet gegevens kunnen leveren die Datum / 106

37 Benodigde functionaliteiten direct in een GIS te gebruiken zijn. Afhankelijk van de door RWS gekozen oplossingsrichting, is het wenselijk om via een website of direct vanuit een RWS bronapplicatitie de CVD te bedienen. Belangrijke functionaliteiten van de CVD zijn: - Zoeken op datum (jaartal) - Zoeken op naam van de kartering - Zoeken op karteringen in een bepaald gebied (zoals RWS beheergebieden) - Technische controle op afgesproken uitwisselstandaard en inhoudelijk op codelijsten zoals gebruikte SALT code. - Feedback voor de gebruiker bij gevonden fouten tijdens de validatie. Catalogibeheer - De medewerker ecologie van RWS vindt het belangrijk dat de gebruikte catalogi centraal beheerd worden zodat alle partijen dezelfde waarden en catalogi gebruiken. - Inhoudelijke experts beheren de catalogi en bepalen 2x per jaar of catalogi gewijzigd worden. Kwaliteitslabel - Inhoudelijke experts bepalen het kwaliteitslabel, zeker voor natura2000 habitatypen - Voor vegetatiekaarten niet echt behoefte aan een kwaliteitslabel Use cases UC-Inl, UC-Acc, UC-CHS, UC-PC, UC-Val, UC-Lak, UC-My, UC-Zoe, UC-Vrij, API-Upl, API-Zoe, UC-Imp, UC-Aan Beleidsmedewerker (natuur) provincie Beleidsmedewerker (natuur) provincie Kennis van het onderwerp Een beleidsmedewerker (natuur) gebruikt vegetatie-en habitatinformatie om het gevoerde beleid te toetsen. Ook voor rapportage ten behoeve van SNL monitoring en Natura2000 zijn deze gegevens belangrijk voor de beleidsmedewerker. Motivatie - Éen centrale voorziening ontwikkelen is efficienter dan 12 verschillende provinciale systemen. - Grote behoefte aan eenvoudig en uniform uitwisselen van vegetatie, habitat en structuurinformatie ten behoeve van SNL monitoring en Natura2000 rapportages. - Als provincie hebben we niet genoeg mankracht om zelf gegevens te verzamelen en te beheren. Eenvoudig vegetatiegegevens opvragen vanuit een centrale voorziening voorziet in de behoefte. Ervaring met technologie De beleidsmedewerker is gewend om te werken met GIS software. Het is voor hem/haar belangrijk dat de informatie uit de CVD te gebruiken is in een GIS. Ook partijen zonder GIS Datum / 106

38 Benodigde functionaliteiten software moeten informatie uit de CVD kunnen raadplegen, bijvoorbeeld als PDF. Belangrijke functionaliteiten van de CVD zijn: - Gemakkelijk kunnen zoeken naar benodige informatie in de CVD - Direct kunnen gebruiken van standaardlegenda s die door de professionals zijn gemaakt - Controleren op overlap (zie IMNa voor regels) Catalogibeheer - De provinciale beleidsmedewerker vindt het belangrijk dat de gebruikte catalogi centraal beheerd worden zodat alle partijen dezelfde waarden en catalogi gebruiken. Kwaliteitslabel - Habitattypekaarten hebben hogere kwaliteitseisen in vergelijking tot vegetatiekaarten. - Kwaliteitslabel voor vegetatiekaarten niet meteen belangrijk. Later wel kwantitatieve en kwalitatieve beoordeling. Use cases UC-Inl, UC-Acc, UC-CHS, UC-PC, UC-Val, UC-Lak, UC-My, UC-Zoe, UC-Vrij, UC-Imp, UC-Aan Medewerker groenbureau Medewerker groenbureau Kennis van het onderwerp Een medewerker groenbureau voert onder andere vegetatiekarteringen uit in opdracht van TBO s, RWS en provincies. De medewerker groenbureau heeft vaak een ecologische of vegetatiekundige achtergrond. Motivatie - De groenbureaus werken in opdracht van TBO s en provincies. Zij worden ook gevraagd om de opgeleverde vegetatiekarteringen en eventuele bijlagen in de CVD op te nemen. Ervaring met technologie Benodigde functionaliteiten De medewerker groenbureau is gewens om met uiteenlopende uitwisselformaten te werken die verschillen per opdrachtgever. Bijvoorbeeld: digitale standaard SBB of formaat van RWS. De groenmedewerker is ook gewend om te werken met GIS software. Het is voor hem/haar belangrijk dat de informatie uit de CVD te gebruiken is in een GIS en dat de informatie eenvoudig aan de CVD aan te leveren is. Belangrijke functionaliteiten van de CVD zijn: - Gemakkelijk kunnen zoeken naar benodige informatie in de CVD - Eenvoudig VegetatieKarteringPackages aanleveren aan de CVD - De mogelijkheid hebben om voor een upload de package te valideren Datum / 106

39 Catalogibeheer - De medewerker groenbureau levert aan volgens het nog af te spreken uitwisselstandaard. Voor deze gebruiker is het van belang dat de catalogi gemakkelijk te vinden zijn. Kwaliteitslabel - Relevant voor de groenbureaus is te weten aan welke kwaliteitseisen voldaan moet worden. Minder relevant is het kunnen toekennen van de kwaliteitslabel. Use cases UC-Inl, UC-Acc, UC-CHS, UC-PC, UC-Val, UC-Lak, UC-My, UC-Zoe, UC-Vrij, UC-Imp, UC-Aan Beleidsmedewerker ministerie van Economische Zaken Beleidsmedewerker ministerie van Economische Zaken Kennis van het onderwerp De beleidsmedewerker van het ministerie van Economische Zaken is mede-verantwoordelijk voor de Europese Natura2000 rapportages. Habitattypekaarten van goede kwaliteit zijn voor hem een speerpunt. Nu is de beleidsmedewerker veel tijd kwijt voor de kwaliteitscontroles van de kaarten. Motivatie - Alle vegetatie-en habitattypekaarten op één plek in de CVD. Momenteel kost het veel tijd om alle gegevens te verzamelen bij verschillende partijen. - Kwaliteit van alle vegetatie-en habitattypekaarten goed beschreven en op te vragen. - Landelijke dekking van vegetatie-informatie die snel op te vragen is. Ervaring met technologie Benodigde functionaliteiten De beleidsmedewerker is gewend om te werken met GIS software. Het is voor hem/haar belangrijk dat de informatie uit de CVD te gebruiken is in een GIS. Ook partijen zonder GIS software moeten informatie uit de CVD kunnen raadplegen, bijvoorbeeld als PDF. Belangrijke functionaliteiten van de CVD zijn: - Zoeken op vegetatie-of habitattype - Zoeken op datum - Zoeken op naam van de kartering - Zoeken op karteringen in een bepaald gebied - Kunnen raadplegen van metadata van de package. Vooral het kunnen nagaan van de kwaliteit van de package is belangrijk - Kunnen raadplegen van vegetatie-opnamen (onderbouwing van vegetatiekaarten en habitattypekaarten) Catalogibeheer - De medewerker TBO vindt het belangrijk dat de gebruikte catalogi centraal beheerd worden zodat alle partijen dezelfde waarden en catalogi gebruiken. - Het is van belang dat de VVN en SBB vegetatietypecatalogi op elkaar worden afgestemd. Datum / 106

40 Kwaliteitslabel - Hoge kwaliteit habitattypekaarten zeer belangrijk voor Natura2000 rapportages. - Bij voorkeur kwalitatieve beoordeling met toelichting. Use cases UC-Inl, UC-Acc, UC-CHS, UC-PC, UC-Val, UC-Lak, UC-My, UC-Zoe, UC-Vrij, UC-Kwa Medewerker onderzoeksinsitituut / onderwijsinstelling Medewerker onderzoeksinstituut / onderwijsinstelling Kennis van het onderwerp Een medewerker van een onderzoeksinstituut of onderwijsinstelling gebruikt de vegetatie-informatie voor uiteenlopende projecten en onderzoeken. Voor ieder onderzoeksgebied dient specifieke vegetatie-informatie verzameld te worden. Motivatie - Alle vegetatie-en habitattypekaarten op één plek in de CVD. Momenteel kost het veel tijd om alle gegevens te verzamelen bij verschillende partijen. - Alle vegetatie-en habitattypekaarten uniform (met dezelfde structuur) opgeslagen. Dit scheelt veel werk bij het samenvoegen, vergelijken en analyseren van de gegevens. Ervaring met technologie Benodigde functionaliteiten De medewerker van een onderzoeksinstituut of onderwijsinstelling is gewend om te werken met GIS software. Het is voor hem/haar belangrijk dat de informatie uit de CVD te gebruiken is in een GIS. Belangrijke functionaliteiten van de CVD zijn: - Zoeken op vegetatietype - Zoeken op datum - Zoeken op naam van de kartering - Zoeken op karteringen in een bepaald gebied - Kunnen raadplegen van metadata van de package. Vooral het kunnen nagaan van de kwaliteit van de package is belangrijk (welke validaties zijn uitgevoerd en is de handmatige controle uitgevoerd?) Catalogibeheer - De medewerker van een onderzoeksinstituut of onderwijsinstelling vindt het belangrijk dat de gebruikte catalogi centraal beheerd worden zodat alle partijen dezelfde waarden en catalogi gebruiken. - Deze catalogi kunnen ook wijzigen, daarom is het nodig om ook de versie van de gebruikte codelijsten in de packages op te kunnen vragen. Kwaliteitslabel - Per package is na te gaan wat het kwaliteitslabel is. Use cases UC-Inl, UC-Acc, UC-CHS, UC-PC, UC-Val, UC-Lak, UC-My, UC-Zoe, UC-Vrij Datum / 106

41 5 Applicatie interface structuur en flow 5.1 Applicatie interface structuur De applicatie heeft de volgende globale opbouw. Headerblok (algemene functies) Menublok Functioneel Blok Footerblok (algemene functies) Header blok Menu blok Functioneel blok Footer blok Figuur 14 Globale opbouw applicatie Header Het header blok bevat Logo(s) Logo van BIJ12 en eventuele andere logo s Titel van de applicatie Voorstel Centrale Vegetatiedatabank (CVD) Standaard functies Home, Contact, Help en Sitemap Algemene zoekfunctie Zoeken in content van de site Login optie Om toegang te krijgen tot de voorziening Datum / 106

42 Header blok Logo(s) Centrale Vegetatiedatabank (CVD) Home Contact Help Sitemap Login Figuur 15 Headerblok Menu Het menublok bevat de verwijzingen naar de hoofdfunctionaliteit van de CVD voorziening. Huidige menu-opties zijn: Registreren o Account aanvragen o Username vergeten? o Password vergeten? Zoeken o o o Mijn Packages Packages zoeken Vrij zoeken Invoeren o Packages aanmaken o Packages importeren Valideren o Technisch valideren o Kwaliteitslabelen Landelijk Beeld o Vegetatie o Habitat o Structuur Beheren o Catalogibeheer o Gebruikersbeheer o Rapportenbeheer Menu blok Registreren Account aanvragen Username vergeten? Password vergeten Zoeken Mijn Packages Packages zoeken Vrij zoeken Invoeren Package aanmaken Package importeren... Valideren Technisch valideren Kwaliteitslabelen... Landelijk Beeld Vegetatie Habitat Structuur Beheren Catalogusbeheer Gebruikersbeheer Rapportenbeheer Figuur 16 Menublok Datum / 106

43 5.1.3 Functioneel blok Het functionele blok wordt ingevuld aan de hand van de gekozen menu-optie en getoond onder de menu-opties. Deze schermen zijn uitgewerkt in de verschillende use cases (zie hoofdstuk 6). Voor het onderdeel Basis Zoeken en Raadplegen Packages wordt het functioneel blok ingedeeld zoals in Figuur 17. Zie ook de website of Figuur 18 voor een soortgelijk ontwerp. Zoekblok (invoeren zoekcriteria) Zoekresultaten kaartblok (toont packages in kaart die aan zoekcriteria voldoen) Zoekresultaten tabelblok (toont packages in kaart die aan zoekcriteria voldoen EN binnen het kaartbeeld (bounding box) vallen) Packagedetails-blok (toont voor een individueel package alle details) o Algemene package-informatie (beschrijving) o Geografische informatie van een package in kaart(en) o Rapporten (pdf) die horen bij het package Header blok Menu blok Zoek blok Zoekresultaten in Kaart Zoekresultaten in Tabel (link met kaart geografisch filter) Package details blok (tab raadplegen + tab downlaoden) Footer blok Figuur 17 Functioneel blok zoeken Na het instellen van zoekcriteria in het zoekblok, worden resultaten die aan de criteria voldoen getoond in kaart en tabel. Inzoomen in de kaart werkt als een geografisch filter op de tabelresultaten. Packagedetails kunnen vanuit de kaart (klik in kaart op package icon) en vanuit tabel ( toon details ) worden aangeroepen. In de tabel kunnen acties op individuele packages Datum / 106

44 (acties per record) of op meerdere packages tegelijk ( tabel acties ) worden uitgevoerd. Een detailscherm toont alle relevante informatie over een package (metadata, kaarten, documenten, etc.) Figuur 18 Schermvoorbeeld GPS Tour Datum / 106

45 Zoek blok (zoekcriteria packages) Uitgebreider zoeken Package Datum Periode en Packages Overige zoek items Overige zoek items Tijdsperiode Naam package Van datum Type Package Tot datum Eigenaar Kwaliteitslabel Protocol... Zoekresultaten in Kaart Zoekresultaten in Tabel (link met kaart bbox kaart = geografisch filter) ID Naam Jaar Type.. Acties 1 xxx 2013 Vegetatiepackage... 2 xxx 2013 Habitat package... Info package 1 Info package 2 Info package xxx xxx xxx Vegetatiepackage Structuurpackage Structuurpackage Tabelacties Downloaden Verwijderen Kwaliteitslabelen... OK Package details blok (tab raadplegen + tab downlaoden) Algemeen Kaarten Rapporten (pdf) Algemene package informatie (pakbon) Detailkaart Lorem ipsum onsectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Package statistieken Package wijzigingshistorie Figuur 19 Basiszoeken en raadplegen packages (gebaseerd op GPS Tour user interface) Datum / 106

46 5.1.4 Footer Het footer blok bevat: Proclaimer Proclaimer tekst aangeleverd door BIJ12 Colofon pagina met achtergrond informatie over de website (o.a. bouwer) Social media links social media icoontjes voor de kanalen die BIJ12 onderhoudt Proclaimer Colofon Social Media Links Figuur 20 Footerblok 5.2 Links naar externe applicaties Tijdens de realisatiefase kan nog besloten worden om bepaalde functionele blokken onder te brengen in externe applicaties. Zo kunnen de landelijke beelden in een externe Flamingo viewer bekeken worden. In dat geval wordt, na het selecteren van de menu-optie in de CVD voorziening, de externe applicatie in een separaat browser scherm (tab) geopend. Datum / 106

47 5.3 Applicatie flow diagram Een Applicatie Flow Diagram geeft aan welke verbanden er tussen de pagina s onderling zijn. Registreren Account aanvragen Package Aanmaken Usernaam vergeten Login Invoeren Package Importeren Wachtwoord vergeten Sitemap Contact Help Home Zoeken MyPackages (tabel kaart) Packages zoeken Vrij zoeken Zoek resultaten Kaart Zoek resultaten Tabel locatie filter Package Details Proclaimer Technisch Valideren Colofon Valideren Kwaliteit Labelen Vegetatie Landelijke beelden Habitat Structuur Catalogus beheer Beheren User beheer Rapport beheer Figuur 21 Applicatie Flow Diagram Datum / 106

48 6 Use cases 6.1 Use Case Overzicht Totaaloverzicht van alle use cases is weergegeven in onderstaande tabel. Par. Code Use Case Toelichting Implementatie 6.3 UC-Inl Inloggen Inloggen op het CVD Standaard loginscherm systeem 6.4 UC-Acc Account aanvragen, Aanvragen van een CVD Standaard aanvraag scherm username vergeten, password vergeten account en opvragen username of password 6.5 UC-CHS Contact, Help, Toont contact formulier, Standaard scherm Sitemap help tekst, sitemap 6.6 UC PC Proclaimer, Colofon Toont proclaimer tekst, colofon tekst Standaard scherm 6.7 UC-Aan Aanmaken package zonder NMS Het aanmaken van een IMNA conform package 6.8 UC-Imp Importeren package Het importeren van IMNA conforme packages 6.9 UC-My Zoeken my Het zoeken (filteren) van packages 6.10 UC-BZR Basis Zoeken en Raadplegen (packages) 6.11 UC-GZR Geavanceerd Zoeken en Raadplegen 6.12 UC-Val Valideren (technisch) eigen packages Het zoeken (filteren) en raadplegen van packages Zoeken over packages heen b.v blauwgrasland Technisch valideren van packages 6.13 UC-Kwa Valideren (kwaliteit) Kwaliteitslabelen van packages Aanmaken van een package door uploaden van benodigde bestanden Uploaden van een package naar de CVD voorziening Geografisch, tijd, kenmerken Geografisch, tijd, kenmerken Query builder met AND en OR opties Valideren vegetatie package Valideren habitat package Valideren structuur package Toekennen van een kwaliteitskenmerk aan 1 of meerdere packages 6.14 UC-LaK Landelijke Kaarten Raadplegen c.q. downloaden van landelijke kaarten 6.15 BUC-Cat Catalogi beheren Beheren van catalogi 6.16 BUC-Usr Users beheren Beheren van users 6.17 BUC-Rap Rapporten beheren Beheren van rapporten 7.1 API-Upl Uploaden packages via API door NMS Zie hoofdstuk API-Zoe Zoeken (en Zie hoofdstuk 7 downloaden) via API door NMS Tabel 3 Overzicht use cases Het kwaliteitlabelen gaat in 2 stappen, (1) interne (bronhouder) validatie + (2) externe autoriteit validatie API API Datum / 106

49 6.2 Samenhang tussen de use cases (use case model) De relatie tussen use cases en de applicatie GUI en API componenten is in onderstaand figuur weergegeven. Figuur 22 Plot Use Cases op Applicatie Componenten GUIs en APIs 6.3 Use Case Inloggen ID Naam Doel Omschrijving User story Primary Actor(s) Secondary actor(s) Precondities, Postcondities Trigger Normal ( happy ) UC-Inl Inloggen Inloggen op het systeem Door het inloggen op het systeem krijgt de gebruiker toegang tot specifieke data en functionaliteit Als gebruiker van de CVD voorziening wil ik kunnen inloggen op het voorziening zodat ik toegang kan krijgen tot data en functionaliteit van de voorziening Alle gebruikers N.v.t. Gebruiker heeft een account Gebruiker is ingelogd op CVD voorziening Gebruiker wil met de CVD voorziening werken 1. Gebruiker gaat naar CVD via URL Datum / 106

50 flow Alternate flow Business rules Niet-Functionele Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) 2. Gebruiker selecteert login optie in header menu 3. Gebruiker voert gebruikersnaam en wachtwoord in 4. Systeem controleert username en password en toont juiste menuopties die toegang bieden tot functionaliteit en data 5. Systeem toont in plaats van login de optie uitloggen Gebruiker wordt geweigerd omdat username-password combinatie niet voorkomt in de user database N.v.t. Basic authenticatie en HTTPS-SSL N.v.t. Standaard login scherm (herkenbaarheid en daarmee gebruikersvriendelijkheid bieden) Standaard login scherm, vergelijkbaar met andere sites Opmerkingen N.v.t. 6.4 Use Case Aanvragen account ID Naam Doel Omschrijving User story Primary Actor(s) Secondary actor(s) Precondities Postcondities UC-Acc Inloggen Systeemaccount kunnen aanvragen Iedere potentiële gebruiker van de CVD voorziening moet een account aanvragen alvorens toegang te kunnen krijgen tot het systeem Als potentiele gebruiker van de CVD voorziening wil ik een account kunnen aanvragen zodat ik toegang kan krijgen tot de CVD voorziening en de daarin beschikbare data en functionaliteit. Alle gebruikers N.v.t. Gebruiker zonder account Verzoek komt bij applicatiebeheerder binnen (lijst van verzoeken). Elk verzoek kan worden toegewezen (rollen en rechten instellen + bericht sturen naar indiener) of afgewezen (bericht afwijzing sturen naar indiener) Datum / 106

51 Trigger Normal ( happy ) flow Alternate flow Business rules Niet-Functionele Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) Gebruiker wil inloggen op de CVD voorziening maar heeft geen account 1. Gebruiker gaat naar login scherm 2. Gebruiker kiest optie aanvragen account 3. Gebruiker voert gegevens in via web form (naam, adres, organisatie, functie 4. Gebruiker bevestigt via knop Registreren 5. Systeem verstuurt verzoek naar applicatiebeheerder en toont bericht aan indiener Uw verzoek is verstuurd naar de applicatiebeheerder van de CVD voorziening, u ontvangt binnen x dagen bericht over uw aanvraag Gebruikersnaam vergeten 1. Gebruiker gaat naar login scherm 2. Gebruiker kiest optie gebruikersnaam vergeten 3. Gebruiker voert adres in 4. Systeem stuurt gebruikersnaam naar gebruiker via 5. Gebruiker logt in met de toegezonden gebruikersnaam Password vergeten 1. Gebruiker gaat naar login scherm 2. Gebruiker kiest optie wachtwoord vergeten 3. Gebruiker voert gebruikersnaam en adres in 4. Systeem stuurt wachtwoord naar gebruiker via 5. Gebruiker logt in met de toegezonden wachtwoord N.v.t. Standaard account aanvraag scherm (herkenbaarheid en daarmee gebruikersvriendelijkheid bieden) 1. User account details (naam*, adres*, organisatie*, functie) 2. Verplichte velden aangeven met * Datum / 106

52 Opmerkingen N.v.t. 6.5 Use Cases Contact, Help, Sitemap ID Naam Doel Omschrijving User story Primary Actor(s) Secondary actor(s) Precondities, Postcondities Trigger Normal ( happy ) flow Alternate flow UC-CHS Contact, Help, Sitemap Standaard website opties Standaard website opties Als gebruiker wil ik op een vertrouwelijke manier contactinformatie, de help of de sitemap kunnen raadplegen Alle gebruikers N.v.t. Website werkt Ingevuld contactformulier, geholpen, genavigeerd Gebruiker wil contact, help of navigeren 1. Gebruiker opent web applicatie (url) 2. Gebruiker klikt op contact, help of sitemap 3. Systeem toont pagina voor contact, help of sitemap a. Contact: gebruiker voert informatie in en verstuurt web formulier b. Help: gebruiker leest help tekst c. Sitemap: gebruiker leest en klikt op onderdeel dat hij zoekt N.v.t. Datum / 106

53 Business rules Niet-Functionele Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) Contactformulier gaat naar helpdesk CVD (of functioneel beheerder) Gegevens van contactformulieren komen binnen bij een helpdeskmedewerker die periodiek (bv. 1x per dag) de binnenkomende contact entries afhandelt (afhankelijk van SLA requirements) N.v.t. Sitemap Menu item usubmenu item uusubsubmenu item uusubsubmenu item usubmenu item usubmenu item Menu item usubmenu item usubmenu item usubmenu item Menu item usubmenu item usubmenu item usubmenu item Opmerkingen N.v.t. 6.6 Use Cases Proclaimer, Colofon ID Naam Doel Omschrijving UC-PC Proclaimer, Colofon Standaard website opties Standaard website opties Datum / 106

54 User story Primary Actor(s) Secondary actor(s) Precondities Postcondities Trigger Normal ( happy ) flow Alternate flow Business rules Niet-Functionele Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) Als gebruiker wil ik herkenbare, eenvoudige standaard website-opties Alle gebruikers N.v.t. Website werkt Gebruiker heeft teksten gelezen Gebruiker wil proclaimer of colofon tekst lezen 1. Gebruiker opent web applicatie (url) 2. Gebruiker klikt op proclaimer of colofon 3. Systeem toont pagina voor proclaimer of colofon a. Proclaimer: toont standaard proclaimer tekst BIJ12 b. Colofon: toont colofon informatie (bvb applicatie bouwer) N.v.t. N.v.t. N.v.t. N.v.t. Opmerkingen Datum / 106

55 6.7 Use Case Aanmaken Package zonder NMS ID UC-Aan Naam Aanmaken Doel Het aanmaken van een package op basis van informatie uit eigen systemen zonder NMS Omschrijving Het uploaden van een FGDB (geo informatie), PDFs (rapporten) en TurboVeg opnamen + invoeren van package metadata via een web formulier. Het CVD systeem creëert vervolgens een IMNA conform package in XML formaat User story Als gebruiker, wil ik vegetatiebestanden in proprietary (bv. Esri) formaat kunnen uploaden, zodat ik vervolgens een IMNA conform XML package bestand kan genereren Primary Actor(s) Medewerker TBO zonder natuurmanagementsysteem Secondary actor(s) Precondities, Postcondities Trigger Normal ( happy ) flow Alternate flow Business rules Niet-Functionele Medewerker RWS (mogelijk op termijn ook via API uploaden, hierover vindt eind januari 2016 nog afstemming plaats) Medewerker provincies Medewerker groenbureau Beheerder (superuser) Benodigde bestanden en informatie: FGDB (template FGDB die gevuld is, vergelijkbare werkwijze als bij natuurbeheerplannen en VRN) PDFs (alleen rapporten, geen geo-informatie!) TurboVeg opnamen Basis informatie van een kartering (metadata) IMNA conform package in XML Gebruiker wil een IMNA conform XML bestand aanmaken om uit te wisselen met een ketenpartner 1. User logt in op CVD 2. User kiest menu optie Aanmaken packages 3. User upload geografische objecten (FGDB o.b.v. IMNA template) 4. User upload rapportages (PDFs) 5. User upload TurboVeg opnamenbestand 6. User voert basis informatie in via web formulier (of info wordt gelezen uit een FGDB tabel importeren uit FGDB ) 7. User klikt op knop aanmaken package 8. CVD systeem maakt XML aan (toont progress bar) en toont vervolgens een bevestigingsbericht met 2 opties: a. Link voor downloaden gecreëerde XML b. Link voor direct uploaden van package naar CVD Aanmaken package mislukt, systeem toont reden van failure Geen codelijst validaties, dat gebeurt pas bij XML packages (o.b.v. XSD schema) Progress bar tonen (gebruiksvriendelijk) + eventueel optie om Datum / 106

56 Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) asynchroon laten lopen (user krijgt een als de package gereed is) 1. Data moet voldoen aan IMNA model zoals geïmplementeerd in de FGDB Template database Stap 1 Invoeren package metadata Stap 2 Toevoegen bestanden (geografie en rapporten) Stap 3 Bevestigingsbericht + download link package XML + link voor direct uploaden van package naar CVD Package Aangemaakt Download package <packagenaam> Package <packagenaam> direct uploaden naar de CVD voorziening Opmerkingen 1. Een vergelijkbare methodiek is geimplementeerd bij NDFF, waarbij file Geodatabase worden omgezet naar XML. Daarnaast, Datum / 106

57 ter voorbeeld, in IMKL worden ook PDFs binary format opgeslagen IN de XML 2. In de ideale (eind)situatie worden alleen nog XML packages gebruikt (i.v.m. mogelijkheid tot XSD schema validatie). Tijdelijk zal het echter noodzakelijk zijn om desktop packages te ondersteunen i.v.m. te verwachten te hoge drempel voor gebruik XML. TBO s met een NMS leveren al wel XML 6.8 Use Case Importeren Package(s) ID UC-Imp Naam Importeren package(s) Doel Importeren van packages om de voorziening te kunnen voorzien van content Omschrijving Het importeren van vegetatie, habitat en structuurpackages naar de CVD voorziening User story Als invoerder wil ik packages kunnen importeren zodat ik deze via de CVD kan aanbieden aan andere stakeholders Primary Actor(s) Medewerker TBO zonder natuurmanagementsysteem Secondary actor(s) Precondities Postcondities Trigger Normal ( happy ) flow Medewerker RWS Medewerker provincies Medewerker groenbureau Applicatiebeheerder (superuser) 1 of meerdere vegetatie, habitat en structuur packages Vegetatie, habitat en structuur packages in de CVD database geladen Gebruiker wil data toevoegen aan CVD 1. Gebruiker logt in op het CVD systeem 2. Gebruiker kiest optie package importeren in menu 3. Systeem toont importeer pagina 4. Gebruiker navigeert naar package(s) en selecteert deze (voor het uploaden kan eventueel ook een drag-drop veld worden aangeboden zodat package in het scherm kunnen worden gesleept) 5. Geselecteerde packages worden getoond in lijst 6. Gebruiker kan eventueel geïmporteerde packages weer verwijderen met verwijder knop achter ieder package 7. Gebruiker bevestigt de import via importeer knop 8. Systeem checkt of package ID al voorkomt in de database, is dat het geval dan volgt een vraag dit package komt al voor in de CVD voorziening, wilt u het bestaande package overschrijven JA/NEE? Datum / 106

58 9. Valide packages worden (na technische validatie op de achtergrond) in de CVD voorziening geladen Alternate flow Business rules Niet-Functionele Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) 1. Bij importeren worden 1 of meer packages geweigerd (komen niet door de technische validatie) 2. Systeem toont welke packages niet zijn geïmporteerd en biedt de gebruiker een import report aan (zie schermvoorbeeld) waarin per geweigerd package staat wat er mis mee is (analoog aan use case Technisch Valideren) Alleen packages van de eigen organisatie kunnen in de CVD voorziening worden geladen. Het CVD systeem matcht hiertoe organisatienaam in package pakbon met organisatienaam verbonden aan user account van ingelogde (GUI) user Een organisatie kan eventueel een andere organisatie machtigen om namens de organisatie data te laden in de CVD Importeren van 1 of meerdere package moet op eenvoudige wijze mogelijk worden gemaakt (gebruiksvriendelijkheid) 1. Geïmporteerde packages worden tijdens de import op de achtergrond technisch gevalideerd Stap 1 Selecteren bestanden Stap 2 Bevestigingsbericht + download link package XML Datum / 106

59 Opmerkingen Het import report bestaat uit een gestructureerde (machine readible) XML (voor Natuur Management Systemen) + voor mensen leesbare variant in HTML of PDF formaat 6.9 Use Case Mijn Packages ID Naam Doel Omschrijving User story Primary Actor(s) Secondary actor(s) Precondities Postcondities Trigger Normal ( happy ) flow UC-My Tonen en beheren eigen packages Tonen en beheren eigen packages Kunnen raadplegen en beheren van eigen packages in CVD voorziening Als gebruiker wil ik direct een overzicht van de packages van mijn eigen organisatie zodat ik deze eenvoudig kan raadplegen en beheren Invoerder Applicatiebeheerder (superuser) Geuploade packages Gewijzigde package lijst (meer of minder packages c.q. aanpassingen in package content of metadata) Gebruiker wil aanpassing doen in eigen packages in CVD 1. Gebruiker logt in op het systeem 2. Gebruiker kiest optie Mijn Packages 3. Systeem toont overzicht van packages van de ingelogde user organisatie (filter op organisatie van ingelogde user) 4. Lijst met getoonde packages kan verder worden gefilterd met filter functionaliteit 5. Applicatie toont lijst van zoekresultaten in kaart en tabel 6. Acties op individuele packages Package details tonen (zie GUI design) Toon in kaart Package data (aanvullend) uploaden Package downloaden Kwaliteits label toekennen Wijzigen package Verwijderen package Datum / 106

60 Alternate flow Business rules Niet-Functionele Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) 7. Acties op meerdere packages ( tabel acties ) Downloaden Kwaliteitslabel toekennen (zie overeenkomstige use case) N.v.t. N.v.t. N.v.t. N.v.t. Zoek blok (zoekcriteria packages) Uitgebreider zoeken Package Datum Periode Tijdsperiode Van datum Tot datum Alleen meest actuele packages tonen en Packages Naam package Type Package Eigenaar Kwaliteitslabel Protocol... Overige zoek items Friesland Groningen Drenthe Overijssel Gelderland Noord-Brabant Limburg Zeeland Overige zoek items Zoekresultaten in Kaart Zoekresultaten in Tabel (link met kaart bbox kaart = geografisch filter) ID Naam Jaar Type.. Acties 1 xxx 2013 Vegetatiepackage... 2 xxx 2013 Habitat package... Info package 1 Info package 2 Info package xxx xxx xxx Vegetatiepackage Structuurpackage Structuurpackage Tabelacties Downloaden Verwijderen Kwaliteitslabelen... OK Package details blok (tab raadplegen + tab downlaoden) Algemeen Kaarten Rapporten (pdf) Algemene package informatie (pakbon) Detailkaart Lorem ipsum onsectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Package statistieken Package wijzigingshistorie Opmerkingen M.b.t. detailinformatie package: waarschijnlijk is het voldoende om de buitengrens te tonen + statistieken over de vegetatietypen en Datum / 106

61 habitattypen die er voorkomen. Definitieve informatie wordt tijdens scrum-agile bouwtraject vastgesteld i.o.m. eindgebruikers 6.10 Use Case Basis Zoeken en Raadplegen Packages ID Naam Doel Omschrijving User story Primary Actor(s) Secondary actor(s) Precondities Postcondities Trigger Normal ( happy ) flow UC-BZR Basis Zoeken en Raadplegen Packages Het kunnen zoeken en raadplegen van packages van de CVD voorziening Het kunnen zoeken en raadplegen van packages van de CVD voorziening Als gebruiker wil ik kunnen zoeken in alle packages in de CVD voorziening, zodat ik precies de packages kan raadplegen (en eventueel vervolgens downloaden) die voor mij relevant zijn Raadpleger Applicatiebeheerder (superuser) Packages in de CVD voorziening Lijst met zoekresultaten waarop acties kunnen worden uitgevoerd (o.a. raadplegen details van een package, downloaden) Gebruiker wil zoeken in CVD voorziening 1. Gebruiker logt in op het CVD systeem 2. Gebruiker kiest optie Packages Zoeken 3. Gebruiker kiest optie Eenvoudig Zoeken of Uitgebreid Zoeken a. Bij eenvoudig zoeken worden meer gebruikte zoekcriteria getoond (parameters zie GUI design) b. Bij uitgebreider zoeken (klik op uitgebreider zoeken ) worden minder gebruikte zoekcriteria getoond 4. Systeem toont zoekresultaten met packages die voldoen aan de zoekvraag in tabel en kaart 5. Inzoomen op kaart betekent geografisch inperken van resultaten in tabel. In kaart worden packages geclusterd getoond. Klikken op een cluster >10 resultaten resulteert in inzoomen en tonen clusters met minder resultaten. Klikken op cluster <10 resultaten levert een popup lijst in de kaart op met packages op die locatie. Vanuit deze lijst is doorklikken naar packagedetails mogelijk. 6. Acties op individuele packages (in tabel) Raadplegen package details (zie GUI design) Toon in kaart Package data (aanvullend) uploaden Package downloaden Kwaliteitslabel toekennen Wijzigen package Verwijderen package Datum / 106

62 Alternate flow Business rules Niet-Functionele Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) N.v.t. 7. Acties op meerdere packages ( tabel acties ) N.v.t. Downloaden Kwaliteitslabel toekennen (zie overeenkomstige use case) Wijzigen en verwijderen alleen mogelijk als de gebruiker daartoe gemachtigd is, anders zijn deze functies uitgegrijsd of worden niet getoond Zoek blok (zoekcriteria packages) Package Datum Periode Tijdsperiode Van datum Tot datum Alleen meest actuele packages tonen en Packages Naam package Type Package Eigenaar Kwaliteitslabel Protocol... Uitgebreider zoeken Overige zoek items Friesland Groningen Drenthe Overijssel Gelderland Noord-Brabant Limburg Zeeland Overige zoek items Zoekresultaten in Kaart Zoekresultaten in Tabel (link met kaart bbox kaart = geografisch filter) ID Naam Jaar Type.. Acties 1 xxx 2013 Vegetatiepackage... 2 xxx 2013 Habitat package... Info package 1 Info package 2 Info package xxx xxx xxx Vegetatiepackage Structuurpackage Structuurpackage Tabelacties Downloaden Verwijderen Kwaliteitslabelen... OK Package details blok (tab raadplegen + tab downlaoden) Algemeen Kaarten Rapporten (pdf) Algemene package informatie (pakbon) Detailkaart Lorem ipsum onsectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Package statistieken Package wijzigingshistorie Opmerkingen M.b.t. detailinformatie package: waarschijnlijk is het voldoende om de buitengrens te tonen + statistieken over de vegetatietypen en Datum / 106

63 habitattypen die er voorkomen. Definitieve informatie wordt tijdens scrum-agile bouwtraject vastgesteld i.o.m. eindgebruikers 6.11 Use Case Geavanceerd Zoeken en Raadplegen Geavanceerd zoeken in gestructureerde data over meerdere packages heen, bijvoorbeeld Blauwgraslanden in heel Nederland. ID Naam Doel Omschrijving User story Primary Actor(s) Secondary actor(s) Precondities Postcondities Trigger Normal ( happy ) flow UC-GZR Geavanceerd Zoeken en Raadplegen Het kunnen zoeken en raadplegen over packages heen in de CVD voorziening Het kunnen zoeken en raadplegen over packages heen in de CVD voorziening Als gebruiker, wil ik over meerdere packages heen kunnen zoeken, zodat ik precies die informatie raadplegen c.q. downloaden die voor mij relevant zijn Raadpleger Applicatiebeheerder (superuser) Packages in de CVD voorziening Lijst met zoekresultaten waarop acties kunnen worden uitgevoerd, o.a. raadplegen in kaart, downloaden Gebruiker wil zoeken in CVD voorziening 1. Gebruiker logt in op het CVD systeem 2. Gebruiker kiest optie Vrij Zoeken a. Bij eenvoudig zoeken worden meer gebruikte zoekcriteria getoond, bv. zoeken op type vegetatie (blauwgrasland case) b. Bij uitgebreid zoeken (klik op uitgebreid zoeken ) wordt een query builder getoond waarmee complexere AND en OR queries kunnen worden samengesteld op de database c. Bij geografisch zoeken is er naast een standaard BBOX van de kaart nog een extra optie om een specifiek zoekgebied (polygoon) te kunnen intekenen. Alleen vegetatiebegrenzingen die geheel binnen c.q. intersecten (instelbaar) met het zoekgebied worden getoond in de tabelresultaten (functionaliteit vergelijkbaar als in TurboVeg en SNL applicatie) 3. Systeem toont zoekresultaat 8. Acties op zoekresultaat Toon in kaart (raadplegen) De kaart toont dan vegetatiekarteringsvlakken c.q. habitatvlakken (eventueel Datum / 106

64 Alternate flow Business rules Niet-Functionele Requirements Data Requirements UML Use Case diagram Ontwerp user interface (GUI) N.v.t. N.v.t. geaggregeerd als 1 getal (aantal) tonen op een kleiner schaalniveau) + de contouren van de packages Geo-informatie downloaden (geaggregeerd) Alleen karteervlakken (bv. blauwgraslanden) in 1 geo-bestand, Met/zonder vegetatieopname als keuze optie aanbieden Packages downloaden originele packages Combi package alleen maar gecombineerde packages o.b.v. landelijke typologie Wijzigen en verwijderen alleen mogelijk als de gebruiker daartoe gemachtigd is, anders zijn deze functies uitgegrijsd of worden niet getoond Schermontwerp wordt i.o.m. eindgebruikers in scrum-agile bouwtraject nader vormgegeven. Mogelijk dat er query builder functionaliteit beschikbaar wordt gesteld zoals hieronder geschetst, Zoek blok (vrij zoeken met query builder) Condities X Vegetatie type = Blauwgrasland OR X Oppervlakte <= 200 OR X Methode = Methode A OR X Kwaliteitslabel = Hoog OR Toevoegen Conditie Grouping Clear Query opslaan Uitvoeren of op vergelijkbare wijze zoals dat bij NDFF is geïmplementeerd. Datum / 106

65 Opmerkingen Bij advanced queries is het goed om te weten wat de dekking is landelijk, provinciaal c.q. regionaal, wat komt er wel/niet voor en hoe komt dat (komt het niet voor of is er geen kartering?) Hiertoe eventueel de beheertypenkaart eronder leggen om beoordeling van query resultaten makkelijker te maken 6.12 Use Case Technisch Valideren Package(s) ID Naam Doel Omschrijving User story Primary Actor(s) Secondary actor(s) UC-Val Valideren Het technisch valideren van een vegetatie, habitat of structuur package De CVD voorziening test het package op de volgende aspecten Encodingvalidatie (bestandscodering) Schemavalidatie (conform IMNa) Codelijstvalidatie Bestandsnaamvalidatie Regelvalidatie Geometrische validatie (conform IMNa + valide geometrie) Referentie validatie Authenticiteitsvalidatie Als validator wil ik functionaliteit waarmee ik packages kan valideren, zodat ik kan controleren of de packages die ik heb gemaakt met mijn eigen software valide zijn en geaccepteerd zullen worden door de CVD import package functionaliteit c.q. API Alle gebruikers Beheerder (superuser) Datum / 106