Programma van Eisen Digitale voedselketeninformatie Casus toezicht kalversector Versie : 1.0 Datum :maart 2012 Auteur : werkgroep kalversector Sggv In licentie gegeven door het ministerie van Economische Zaken, Landbouw en Innovatie op grond van de Creative Commons licentie -NietCommercieel-GelijkDelen (http://creativecommons.org/licenses/bync-sa/3.0/nl/).
Inhoudsopgave 1 Inleiding...3 1.1 Achtergrond van de casus toezicht kalversector...3 1.2 Doel van de casus toezicht kalversector...3 1.3 Doel en doelgroepen van dit document...4 1.4 Korte schets van de DVKI...4 1.5 Groeipad van de DVKI...5 1.6 Indeling van dit document...6 2 Belanghebbenden en wensen...7 3 Algemene eisen aan de portal...8 3.1 Bruikbaarheid...8 3.2 Koppelbaarheid...8 3.3 Beveiliging en Betrouwbaarheid...9 4 Eisen aan de DVKI webservices...11 5 Eisen aan de DVKI applicatie...12 5.1 Kwaliteitseisen...12 5.2 Functionaliteit...12 5.3 Betrouwbaarheid...13 5.4 Bruikbaarheid...14 5.5 Efficiëntie... 14 5.6 Onderhoudbaarheid...15 5.7 Overdraagbaarheid...15 6 Domeinmodel DVKI...16 6.1 Koppel...17 6.2 Kalf...17 6.3 Houder heden...18 6.4 Houder verleden...18 6.5 Digitale VKI...19 6.6 Slachthuis...19 6.7 Machtiging...20 7 Use-case-model DVKI...21 7.1 Inleiding...21 Pagina 1
7.2 Aanmaken accounts voor IKB deelnemer...21 7.3 Aanvragen account voor niet-ikb deelnemer...22 7.4 Persoon activeert account...22 7.5 Gebruiker beëindigt gebruikersaccount...23 7.6 Gebruiker logt uit...23 7.7 Afgeven machtiging...23 7.8 Intrekken machtiging...24 7.9 Invoer VKI...25 7.10 Historie ingevoerde VKI inzien...27 7.11 Muteren ingevoerde VKI...27 7.12 Status afvoermeldingen inzien...28 7.13 Controle aanwezigheid VKI door handel...28 7.14 Ophalen VKI door slachterijen...29 7.15 Vastleggen (slacht)keurgegevens door Slachthuis...29 7.16 Inzien slachtkeurgegevens door Kalverhouder...30 7.17 Vastleggen opmerkingen VKI door Slachtmeester/NVWA...30 7.18 Inzien opmerkingen VKI door Slachterij/NVWA...30 7.19 Beheerder DVKI voert beheer uit...31 Lijst van afbeeldingen Afbeelding 1. Schematische weergave van de structuur van DVKI...5 Afbeelding 2. Domeinmodel voor de DVKI....16 Pagina 2
1 Inleiding 1.1 Achtergrond van de casus toezicht kalversector Het ministerie van Economische Zaken, Landbouw & Innovatie (hierna EL&I) wil de administratieve lasten voor ondernemers in de landbouwsector verminderen. Het programma Slim geregeld, goed verbonden (hierna Sggv) van dit ministerie, dat zich richt op snellere en goedkopere informatieuitwisseling tussen overheid en bedrijfsleven, is hiertoe in 2009 gevraagd te onderzoeken of in de landbouwsector mogelijkheden bestaan voor potentiële besparingen. De toen uitgevoerde inventarisatie geeft als conclusie dat binnen de kalfsketen mogelijkheden bestaan om de kosten voor controle en toezicht te verlagen door verdere digitalisering en verbetering van de informatieuitwisseling tussen de kalversector en de overheid. In begin 2010 heeft EL&I aan SGGV gevraagd een intake uit te voeren voor deze casus. Deze intake biedt de basis voor overheden en bedrijfsleven om deze casus te starten en is het startpunt geweest voor het plan van aanpak. Kijkende naar het toezicht in de kalversector dan staat hierin centraal de eigen verantwoordelijkheid van de bedrijven voor de kwaliteit in de keten. Bij het borgen van de kwaliteit wordt op een drietal aspecten gekeurd en toezicht gehouden: voedselveiligheid (o.a. hygiëne, schadelijke afwijkingen en gebruik van antibiotica); dierenwelzijn (o.a. huisvesting en transport), en diergezondheid (besmettelijke dierziekten). Uitgangspunt voor de digitalisering van de informatie-uitwisseling is voedselveiligheid. Echter de uitvoering van de vele verordeningen op de drie kwaliteitsaspecten levert een veelheid aan toezichten kwaliteitssystemen op. Ook binnen deze casus kunnen de drie aspecten niet geheel los van elkaar benaderd worden. Een gedetailleerde achtergrond bij de casus is te lezen in het plan van aanpak.. 1.2 Doel van de casus toezicht kalversector Samengevat is het doel van het de casus toezicht kalversector : een snellere, kwalitatief betere en goedkopere informatie-uitwisseling tussen overheid en bedrijfsleven in de kalversector wat leidt tot een vermindering van de administratieve lasten voor ondernemers in de sector en een beperking van de keuringslast voor de inspectiediensten. Pagina 3
Het resultaat van de casus bestaat uit drie onderdelen waarbij het eerste onderdeel geldt als het fundament voor de overige onderdelen. Dit eerste onderdeel, onderdeel A Digitalisering van de voedselketeninformatie (VKI) en de terugkoppeling van keuringsresultaten door de toezichthouder, richt zich op het voortzetten van een door de sector reeds ingezette richting van het volledig digitaliseren van de VKI door middel van een door de sector beheerd systeem. Hiernaast zullen de slachtkeuringsgegevens van de toezichthouder middels ditzelfde systeem teruggekoppeld kunnen worden aan de kalverketen. Door de digitale VKI leidend te maken in het proces kan de papieren stroom omtrent de VKI worden afgeschaft. Hierdoor ontstaat een basis voor optimalisatie van de gegevensstroom. Dit onderdeel zal kwalitatieve gevolgen hebben voor zowel de sector als de toezichthouder, eveneens zullen besparingen worden gerealiseerd op administratieve lasten en mogelijkheden worden gegeven voor besparingen in bedrijfsprocessen. De veranderingen die deze digitalisering met zich mee zal brengen staan beschreven in het Ist document en Soll document dat als bijlage bij het plan van aanpak is aangeboden.. 1.3 Doel en doelgroepen van dit document Om het digitaliseren van de voedselketeninformatie te beproeven wordt door het programma Sggv in samenwerking met de sector een eerste versie van een systeem (werktitel DVKI) gerealiseerd. Dit prototype wordt eind 2011 beproefd door een beperkt aantal kalverhouders, slachthuizen en toezichthouders van de NVWA om te beoordelen of het concept, ondersteund door het systeem, daadwerkelijk de verwachte verbeteringen in de verwerking van de voedselketeninformatie oplevert. Doel van dit PvE is om de deelnemers inzicht te geven in de beoogde functionaliteit voor de praktijktest en de bouwer van het systeem te ondersteunen in het realiseren van de eerste versie. Het PvE beschrijft vooral wat de DVKI moet doen en niet hoe dat moet. 1.4 Korte schets van de DVKI De DVKI is een webapplicatie. Het idee is dat deze webapplicatie onderdeel is van de SKV website en bestaat uit de volgende functionele onderdelen: Autorisatie en toegangsmodule Algemeen deel met registratie van bedrijfsgegevens (basisgegevens) Registratiemodule voor VKI gegevens Registratiemodule voor slachtkeurgegevens Machtigingendeel/beheermodule Gegevensopslag Pagina 4
Koppelvlakken met externe webservices Het vastleggen van koppel doet SKV buiten dit systeem DVKI De afbeelding hieronder toont hier een schematische weergave van. Afbeelding 1. Schematische weergave van de structuur van DVKI. Toegang en autorisatie Registratie VKI Registratie slachtkeurgeg. Registratie algemeen machtiginge n webservice s gegevensopsla g. 1.5 Groeipad van de DVKI De eerste versie van de DVKI biedt minimaal de functionaliteit die nodig is om een digitale VKI te kunnen opmaken, te kunnen aanbieden en de slachtkeurgegevens van een koppel te kunnen vastleggen. In de doorontwikkeling kan de DVKI worden verbreed naar keteninformatiesysteem voor de kalversector. Daarvoor moeten meer gegevens worden vastgelegd in het systeem en kan de VKI geautomatiseerd worden opgemaakt. Pagina 5
1.6 Indeling van dit document Dit document beschrijft de eisen aan de webapplicatie. Hoofdstuk 2 beschrijft de belanghebbenden en hun wensen. Hoofdstuk 3 beschrijft de algemene eisen die op alle onderdelen van toepassing zijn. De hoofdstukken daarna beschrijven per onderdeel de eisen specifiek voor dat onderdeel. Voor de DVKIapplicatie zijn naast de eisen ook de use cases 1 benoemd en beschreven. 1 Een use case is een begrip uit de software-ontwikkeling. Een use-case-model beschrijft welke gebruikers op welke wijzen gebruik kunnen maken van een applicatie. Pagina 6
2 Belanghebbenden en wensen Dit hoofdstuk beschrijft de belanghebbenden bij de DVKI en hun belangrijkste behoeften. De volgende belanghebbenden zijn te onderscheiden: Aanbieder: de aanbieder is de organisatie die de DVKI laat ontwikkelen en aanbiedt voor gebruik (de stichting SKV); Gebruiker DVKI. De gebruiker van de DVKI heeft een gebruikersaccount. De gebruikerstypen zijn: Kalverhouder Slachthuis NVWA Dierenarts veehouder Handelaar/transporteur Verzamelplaats Beheerder/admin Medewerker SKV Deze gebruikerstypen kunnen DVKI diensten gebruiken zoals aangegeven in het dienstenoverzicht in bijlage A. Naast de primaire gebruikersrollen zijn er ook beheerrollen te onderkennen. Dit PvE maakt geen onderscheid tussen de verschillende beheerrollen maar beschrijft de eisen vanuit beheer in het algemeen. De gebruikers hebben naast de primaire diensten van DVKI uit hst 7 de volgende wensen: Een kalverhouder wil naast opmaken van de VKI-koppel ook de afvoermeldingen kunnen authoriseren vanuit DVKI en de status kunnen opvragen. Gebruikers moeten behalve via het webportaal van DVKI ook gegevens kunnen invoeren/opvragen via een callcenter en webservices. Pagina 7
3 Algemene eisen aan de portal 3.1 Bruikbaarheid Een gebruiker kan met hetzelfde gebruikersaccount zowel handelen namens zichzelf of handelen als gemachtigde namens een andere partij. De webapplicatie is in het Nederlands. De opzet komt overeen met de opzet van InfoRund, maar dan met de huisstijl van SKV (zie www.skv.info). Naast de invoer o.b.v. levensnummer en werknummer zal het ook mogelijk zijn op basis van een koppelnummer VKI in te voeren. Tevens zal het mogelijk zijn reeds ingevoerde VKIformulieren te wijzigen. Bezoekers en gebruikers hebben op iedere plek op de website van de DVKI het gevoel te weten waar ze zijn, wat ze zien en waar ze naartoe kunnen. Belangrijk zijn browseronafhankelijkheid en goede toegankelijkheid, ook voor minder digitaal vaardige gebruikers. 3.2 Koppelbaarheid De website maakt gebruik van actuele open standaarden, in het bijzonder die steun krijgen vanuit het W3C. Afwijking mag alleen met expliciete toestemming van de eigenaar. De DVKI portal is zonder problemen en verlies van functionaliteit te gebruiken in de volgende gangbare, moderne webbrowsers, minimaal in de laatste twee hoofdversies van: Firefox. Google Chrome Microsoft Internet Explorer Opera Safari E-mails afkomstig van de DVKI-applicatie zijn duidelijk leesbaar in gangbare moderne email-clients, minimaal in de laatste twee hoofdversies van: Windows Mail Pagina 8
Microsoft Outlook Express Microsoft Outlook Lotus Notes Thunderbird Apple Mail Gmail Statistieken van het gebruik van de website DVKI zijn inzichtelijk te maken. 3.3 Beveiliging en Betrouwbaarheid Beveiliging dient een integraal onderdeel te zijn van de DVKI die betrouwbaar en veilig moet functioneren. Zowel uit het perspectief van de gebruiker als van de beherende eigenaar. Deze moeten op de juistheid en volledigheid van het systeem aankunnen en informatie in vertrouwen kunnen delen. De ingang van beheer en het content-management-systeem is gescheiden van de publieke toegang en alleen bereikbaar vanuit het beheerdersaccount. In het kader van traceerbaarheid worden diverse acties gelogd. Een voorbeeld hiervan is het loggen van IP adressen van waaruit VKI is ingevoerd en opgevraagd. De logbestanden zijn te allen tijde op te halen vanuit de database. Een aangemelde gebruiker kan zich afmelden, de sessie is daarmee beëindigd. Na een configureerbare periode van inactiviteit van de gebruiker meldt de applicatie een gebruiker automatisch af. Beveiliging van de omgevingscomponenten (bestaande uit huisvesting, infrastructuur, platform en applicaties) is op elkaar afgestemd. De omgeving voorziet in inbraakpreventie en is voorzien van een SSL certificaat. Er is actief veiligheidsbeheer op de omgeving voorzien; in het bijzonder moeten platform en infrastructuur naast het reguliere onderhoud beschikken over de meest recente patches en updates die relevant zijn uit het oogpunt van veiligheid. Naast de reguliere testen kan bij grote wijzigingen in de omgeving of wanneer de laatste test meer dan een jaar geleden is een penetratietest door een onafhankelijke partij uitgevoerd worden. Pagina 9
Wijzigingen in systemen of software moeten succesvol zijn getest voor het in productie nemen. Testen met productiegegevens gebeurt alleen indien de houder van het UBN hier toestemming voor heeft gegeven. De testgegevens op de productieomgeving worden binnen afzienbare tijd uit het systeem verwijderd. Pagina 10
4 Eisen aan de DVKI webservices DVKI is via webservices koppelbaar met andere applicaties. Via deze webservices is het mogelijk DVKI gegevens in te voeren en op te vragen. Bij het aanleveren en opvragen van gegevens dient een authenticatie (username en wachtwoord) meegegeven te worden. Alleen als deze geverifieerd wordt kan de gewenste actie succesvol uitgevoerd worden. Bij het aanleveren en opvragen van gegevens wordt het IP adres gelogd. De webservices zijn beveiligd en beschikken over een SSL certificaat. DVKI beschikt voor de praktijktest over onderstaande webservices: Webservice voor het real time bevragen van I&R voor diergegevens Webservice voor het ophalen van VKI door een slachthuis Aanleveren van slachtkeurgegevens op diernummer door een slachthuis (indien gewenst) Pagina 11
5 Eisen aan de DVKI applicatie 5.1 Kwaliteitseisen Voor de beschrijving van de kwaliteitseisen aan de DVKI is gebruik gemaakt van de indeling van het Extended ISO 9126 Model, ook wel het Quintmodel genoemd. Zie www.softwarekwaliteit.nl. Dit model onderscheidt de volgende kwaliteitseigenschappen: Functionaliteit: geschiktheid, accuraatheid, koppelbaarheid, compliance, beveiliging, traceerbaarheid. Betrouwbaarheid: volwassenheid, fouttolerantie, herstelbaarheid, beschikbaarheid, degradeerbaarheid. Bruikbaarheid: begrijpelijkheid, leerbaarheid, gebruiksgemak, explicietheid, aanpasbaarheid, aantrekkelijkheid, duidelijkheid, behulpzaamheid, gebruiksvriendelijkheid. Efficiëntie: tijdsgedrag, resourcegedrag. Onderhoudbaarheid: analyseerbaarheid, veranderbaarheid, stabiliteit, testbaarheid, beheerbaarheid, herbruikbaarheid. Overdraagbaarheid: aanpasbaarheid, installeerbaarheid, conformance, vervangbaarheid. 5.2 Functionaliteit De functionaliteit van de DVKI-applicatie is beschreven in het use-case-model. Hieronder volgt een aantal algemene eisen die bepalend zijn voor de invulling van de use cases. 5.2.1 Geschiktheid Self-service Om de beheerlast te beperken wordt gestreefd naar zoveel mogelijk self-service door de gebruikers. Voorbeelden hiervan zijn het zelf resetten van een password, machtigingen beheren en het annuleren van afvoermeldingen. Historie Wijzigingen worden geregistreerd. Geregistreerd wordt welke gebruiker op welk moment welk gegeven heeft gecreëerd. Pagina 12
5.2.2 Beveiliging De beveiliging van de DVKI-applicatie is opgezet conform NEN-ISO/IEC 27001:2005 nl en NEN- ISO/IEC 27002:2007 zoals opgenomen in de lijst van standaarden voor pas toe of leg uit van het Forum en College Standaardisatie, www.open-standaarden.nl. Daarnaast voldoet de DVKI-applicatie aan het Raamwerk Beveiliging Webapplicaties van GOVCERT: Raamwerk beveiliging webapplicaties, GOVCERT.NL, versie 1.3, 27 oktober 2006. De ontwikkeling van de DVKI voldoet aan de OWASP Guide to Building Secure Web Applications and Web Services: A Guide To Building Secure Web Applications and Web Services, july 27, 2005, owasp.org. De ontwikkeling moet in het bijzonder principes van defensief programmeren toepassen. Modularisatie, invoervalidatie, foutafhandeling en betekenisvolle logbestanden zijn als zodanig vereist. De applicatie voorziet in functiescheiding. In het algemeen geldt dat alleen een geautoriseerde gebruiker toegang heeft tot die gegevens en functies waar deze gebruiker vanuit zijn rol of initiatief bij mag. Een beheerder is in deze ook een gebruiker. De applicatie geeft een gebruiker tijdens een sessie alleen toegang tot persoonlijke, initiatief en rolgebonden gegevens of functies nadat deze de gebruikersnaam met bijbehorend wachtwoord heeft ingevoerd om zich aan te melden. 5.3 Betrouwbaarheid De verwachte continuïteit van de DVKI is 7 x 24 uur. Zonder onderbreking moet deze beschikbaar kunnen zijn. De eis aan beschikbaarheid ligt op 98%, dit vertaalt zich naar een maximale uitval van 7,3 dagen op jaarbasis. De systeemomgeving wordt elke 5 minuten gerepliceerd naar een server ten kantore van SKV. Hierdoor is altijd een back-up van maximaal 5 minuten oud beschikbaar. Hierdoor is een potentieel gegevensverlies bij het onvoorzien uitvallen zeer gering. Voor beheer (de bewaking van de betrouwbaarheid) is er voorzien in een periodieke rapportage ten aanzien van het middelenbeslag en gedrag van de applicatie, realtime monitoring van de applicatie en Pagina 13
alarmering van ernstige anomaliteiten, storingen die de betrouwbaarheid kunnen schaden. 5.4 Bruikbaarheid De context van een pagina is voor de gebruiker altijd duidelijk. Duidelijk zichtbaar is tot welk UBN, individueel dier of koppel de pagina behoort, indien relevant. Notificatie-emails zijn duidelijk afkomstig van de DVKI. Dit blijkt uit het email-adres van de afzender en uit het onderwerp. Notificatie-emails bevatten voldoende informatie voor de gebruiker om te kunnen besluiten of vervolgacties nodig zijn en om eventuele vervolgacties uit te voeren. Het moet niet nodig zijn voor de gebruiker om naar aanleiding van een notificatie-email in te loggen op de DVKI om over voldoende informatie te beschikken. Bij een foutsituatie, om welke reden dan ook, dienen foutmeldingen getoond te worden. Deze foutmeldingen moeten informatie bevatten wat de gebruiker moet doen of welke actie de website gaat uitvoeren. Foutmeldingen mogen niet negatief/straffend geformuleerd zijn. 5.5 Efficiëntie Rekening dient te worden gehouden met de volgende aantallen gebruikers. Eerste jaar Tweede jaar Derde jaar en verder Aantal nieuwe 3.000 100 100 gebruikers per jaar Aantal actieve 3.000 3.000 3.000 gebruikers Gelijktijdige 3.000 3.000 3.000 gebruikers Gemiddelde gegevensomvang per UBN MB MB GB Pagina 14
De volgende responsetijden dienen te worden gehaald: 3 seconden, maximaal 15 seconden toelaatbare wachttijd. Zie http://www.websiteoptimization.com/speed/tweak/web-page-performancethesis/. 5.6 Onderhoudbaarheid De voorbereidingsmodule moet goed onderhoudbaar zijn; van iedere versie, revisie voor productie is actuele broncode en actuele documentatie beschikbaar met een beschrijving van de wijzigingen ten opzichte van de voorgaande versie. Er is gebruik gemaakt van gangbare methodieken voor software-ontwikkeling die de onderhoudbaarheid bevorderen zoals: codeerstandaards, automatische code analyse, unit testen en defensief programmeren. De eigenaar van de DVKI kan besluiten een analyse van de kwaliteit van de software uit te (laten) voeren. 5.7 Overdraagbaarheid De omgeving is dusdanig ingericht en gedocumenteerd dat aan het einde van het contract een leverancier de dienstverlening kan overdragen aan een willekeurige andere partij. De omgeving en in het bijzonder de applicaties zijn niet afhankelijk van licenties, patenten of andere bijzondere rechten waarvoor de eigenaar geen expliciete goedkeuring heeft gegeven. Dit heeft het doel ongewenste afhankelijkheden die de overdraagbaarheid belemmeren te voorkomen. Pagina 15
6 Domeinmodel DVKI Het domeinmodel benoemt de relevante onderwerpen van gesprek binnen de scope van de DVKI en de relaties en eigenschappen ervan. Het domeinmodel is vooral een model van de relevante werkelijkheid en van de belangrijkste gegevens van DVKI. Het domeinmodel is geen model van de gegevensopslag in de DVKI; het is geen relationeel gegevensmodel. Het laat ook het aspect historie (wijziging van gegevens) buiten beschouwing. Eigenschappen als tijdstippen van registratie en wijziging zijn daarom niet in het domeinmodel opgenomen. De afbeelding hieronder toont het domeinmodel als UML class diagram. Dit hoofdstuk beschrijft de verschillende objecttypen in het domeinmodel, zoals houder, koppel en kalf, de relaties tussen deze objecttypen en de relevante eigenschappen ervan. Afbeelding 2. Domeinmodel voor de DVKI. Pagina 16
6.1 Koppel Definitie: Groep dieren met dezelfde gezondheids- en immuniteitsstatus, die in eenzelfde lokaal of een zelfde uitloopruimte wordt opgefokt en die een epizoötiologische eenheid vormen. Relaties: Een koppel omvat één of meer kalveren Eigenschappen: Een koppel heeft een uniek (AM91) identificerend nummer. Een koppel wordt vastgelegd door SKV (Stichting Kwaliteitsgarantie Vleeskalversector) Toelichting: Gebruik van een koppel heeft als voordeel dat mutaties die voor alle dieren uit een koppel gelden eenvoudig kunnen worden geregistreerd. 6.2 Kalf Definitie: Een kalf is in de context van DVKI een slachtkalf niet ouder dan 12 maanden waarover gedurende de levensloop gegevens worden bijgehouden die van belang zijn voor de voedselveiligheid. Relaties: Een kalf behoort tot precies één koppel Een kalf is op een moment in de tijd de verantwoordelijkheid van precies één houder heden. Een kalf is afkomstig van precies één houder verleden Eigenschappen: Een kalf heeft een uniek levensnummer en eigenschappen vastgelegd in het bronsysteem I&R van EL&I Van een kalf worden slachtkeurgegevens vastgelegd Een kalf heeft een medische historie/gezondheidsstatus, vastgelegd door de houder(s). Toelichting: In het prototype zal de medische historie nog niet worden vastgelegd. Alleen het resultaat van de historie wordt vastgelegd door middel van de opmaak van een VKI formulier. Pagina 17
6.3 Houder heden Definitie: Een natuurlijke of rechtspersoon die op moment van opmaak van de VKI verantwoordelijk is voor de slachtkalveren. Relaties: Een houder heden huisvest één of meer kalveren Een houder heden is verantwoordelijk voor de opmaak van één of meer VKI formulieren Een houder heden levert een koppel aan één of meer slachthuizen Een houder heden verleent één of meer machtigingen aan derden Eigenschappen: Een houder heden heeft een uniek identificerend UBN afkomstig uit het bronsysteem I&R Een houder heden heeft een set basisgegevens afkomstig uit het bronsysteem I&R Toelichting: Ook een slachthuis is op een bepaald moment in de tijd een houder maar nooit een houder heden die een VKI opmaakt. 6.4 Houder verleden Definitie: Een natuurlijke of rechtspersoon die op enig moment verantwoordelijk is geweest voor de slachtkalveren. Relaties: Een houder verleden huisvestte één of meer kalveren Eigenschappen: Een houder verleden heeft een uniek identificerend UBN afkomstig uit het bronsysteem I&R Een houder verleden heeft een set basisgegevens afkomstig uit het bronsysteem I&R Toelichting: De houder verleden kan een rol spelen in de medische historie van een dier. DVKI legt alleen vast wat Pagina 18
het resultaat is van de medische historie. De houder heden is verantwoordelijk voor een juiste verwerking van alle bekende medische gegevens. 6.5 Digitale VKI Definitie: Een digitale verklaring van de houder heden omtrent de voedselveiligheid van één of meerdere kalveren Relaties: Digitale VKI omvat één of meerdere kalveren Digitale VKI kan gebundeld worden per koppel Digitale VKI is de verantwoordelijkheid van precies één houder heden Digitale VKI kan door één of meer slachthuizen opgevraagd worden Eigenschappen: Digitale VKI bevat antwoorden op een vaste set vragen Digitale VKI kan voor zowel individuele levensnummers als koppels ingevoerd worden Digitale VKI wordt per levensnummer opgeslagen Digitale VKI kan zowel voor individuele levensnummers als koppels opgevraagd worden door slachthuizen Digitale VKI wordt per levensnummer teruggekoppeld aan slachthuizen Toelichting: 6.6 Slachthuis Definitie: Een slachthuis ontvangt slachtkalveren en de daarbij horende VKI Relaties: Een slachthuis ontvangt VKI Een slachthuis ontvangt koppels van één of meer houder heden. Eigenschappen: Pagina 19
Een slachthuis beoordeelt de VKI en legt de bevindingen vast In een slachthuis worden keuringen verricht en gegevens daarover vastgelegd Toelichting: 6.7 Machtiging Definitie: Verklaring van een houder dat een derde namens hem mag handelen Relaties: Een machtiging hoort bij precies één houder heden Eigenschappen: Een machtiging wordt vastgelegd in DVKI Toelichting: Pagina 20
7 Use-case-model DVKI 7.1 Inleiding Het use-case-model 2 beperkt zich tot de DVKI zelf. Het use-case-model benoemt de use cases en beschrijft de benodigde functionaliteit voor de gebruiker globaal. De use-case-beschrijvingen abstraheren van een specifieke invulling en gebruikersinterface. Het programma van eisen bevat dan ook geen use-case-specificaties. De specificatie en invulling van de use-cases dient plaats te vinden in afstemming tussen de aanbieder en de ontwikkelaar van de DVKI. De volgende punten zijn van toepassing op alle use cases: De in de use cases relevante gegevens zijn gedefinieerd in het domeinmodel. In de beschrijving van de use cases worden deze gegevens niet herhaald, tenzij onduidelijk is welke eigenschappen of relaties het betreft. Door de gebruiker ingevoegde gegevens worden gevalideerd door het systeem. Het systeem geeft aan waar de gebruiker eventuele invoerfouten heeft gemaakt en geeft de gebruiker de mogelijkheid deze fouten te corrigeren. 7.2 Aanmaken accounts voor IKB deelnemer Doel: Gebruikerstype afhankelijke accounts aanmaken. Aanleiding: Alle IKB Vleeskalveren gecontracteerde veehouders worden per brief geïnformeerd over het systeem en de persoonlijke inloggegevens Actor: SKV (voor het aanmaken van de accounts) Beschrijving: SKV ontvangt per gebruikerstype adresbestanden. SKV maakt accounts aan waarbij de toegekende diensten gebruikerstype afhankelijk zijn. 2 Een use case is een begrip uit de software-ontwikkeling. Een use-case-model beschrijft welke gebruikers op welke wijzen gebruik kunnen maken van de applicatie. Pagina 21
7.3 Aanvragen account voor niet-ikb deelnemer Doel: Een persoon vraagt een account aan om gebruik te kunnen maken van de DVKI. Registratie voorkomt dat willekeurige personen gebruik kunnen maken van de DVKI en toegang hebben tot de gegevens in de DVKI. Aanleiding: een persoon geeft aan een gebruiksaccount te willen verkrijgen Actor: persoon (bezoeker website) Beschrijving: De persoon geeft aan een account voor DVKI te willen hebben door telefonisch of per mail contact op te nemen met SKV De persoon stelt de benodigde gegevens voor het aanmaken van een account beschikbaar aan SKV. SKV maakt een gebruikerstype afhankelijk account aan voor desbetreffend persoon op grond van de aangeleverde gegevens en sectorafspraken. SKV stuurt een bericht met inloggegevens naar desbetreffend persoon. 7.4 Persoon activeert account Doel: De persoon activeert het account om gebruik te kunnen maken van de DVKI. Activering zorgt ervoor dat alleen personen die er zelf voor kiezen en een geldig e-mailadres hebben opgegeven gebruik kunnen maken van DVKI. Aanleiding: de persoon wil het account activeren Actor: persoon die inloggegevens heeft ontvangen. Beschrijving: De persoon logt m.b.v. de inloggegevens in op de website van DVKI. Het systeem geeft aan dat de persoon de gebruiksvoorwaarden voor de digitale portalen van SKV dient te accepteren en biedt de persoon de mogelijkheid deze voorwaarden te bekijken. De persoon geeft aan de gebruiksvoorwaarden te accepteren. Het systeem geeft aan dat de persoon het wachtwoord eenmalig dient te wijzigen. De persoon wijzigt het wachtwoord. Indien nog niet bekend geeft het systeem aan dat de persoon een emailadres in moet voeren.. De persoon voert een emailadres in. Pagina 22
Het systeem geeft aan dat de persoon de gebruiksvoorwaarden voor DVKI dient te accepteren en biedt de persoon de mogelijkheid deze voorwaarden te bekijken. De persoon geeft aan de gebruiksvoorwaarden te accepteren. Het account is geactiveerd 7.5 Gebruiker beëindigt gebruikersaccount Doel: De gebruiker beëindigt zijn gebruikersaccount zodat deelname aan de DVKI niet meer mogelijk is. Aanleiding: De gebruiker geeft aan zijn gebruikersaccount te willen beëindigen. Actor: gebruiker met actief account Beschrijving: De gebruiker geeft aan zijn gebruikersaccount te willen beëindigen door middel van mail- of telefonisch contact met SKV. SKV deactiveert de dienst DVKI bij desbetreffende gebruiker. 7.6 Gebruiker logt uit Doel: de gebruiker logt uit om gebruik van DVKI te beëindigen. Uitloggen voorkomt dat een andere persoon via de computer van de gebruiker toegang kan krijgen tot de DVKI. Aanleiding: gebruiker geeft aan uit te willen loggen. Actor: ingelogde gebruiker. Beschrijving: De gebruiker geeft aan uit te willen loggen. Het systeem logt de gebruiker uit en toont aan de gebruiker dat deze is uitgelogd. De gebruiker kan op elke pagina aangeven dat hij wil uitloggen. 7.7 Afgeven machtiging Doel: de gebruiker machtigt derden voor het afgeven en/of inzien van bepaalde gegevens namens de gebruiker. Pagina 23
Aanleiding: gebruiker geeft aan een machtiging aan derden af te willen geven Actor: Ingelogde gebruiker Beschrijving: De gebruiker geeft aan een machtiging af te willen geven. De gebruiker selecteert een derde 3 door naam of UBN in te voeren in zoekvenster. Het systeem toont de zoekresultaten. De gebruiker selecteert een derde. Afhankelijk van het gebruikerstype van de gebruiker en derde worden de mogelijk te machtigen diensten getoond. Per keer kan één gebruiker voor meerdere diensten gemachtigd worden. De gebruiker selecteert de te machtigen diensten. De gebruiker klikt op OK waarna een middels een panel een bevestiging wordt gevraagd. De machtiging is geactiveerd. De derde kan via het overzicht in Mijn Portaal de machtiging inzien 7.8 Intrekken machtiging Doel: De gebruiker trekt een eerder uitgegeven machtiging aan derden in Aanleiding: De gebruiker heeft aangegeven een eerder uitgegeven machtiging aan derden in te willen trekken. Actor: Ingelogde gebruiker Beschrijving: De gebruiker geeft aan een machtiging in te willen trekken De gebruiker gaat via het overzicht met uitstaande machtigingen naar het detailoverzicht voor desbetreffende derde. De gebruiker haalt alle machtigingen voor één gebruiker tegelijk weg of haalt de individuele vinkjes bij de in te trekken machtigingen voor de diverse diensten weg. De gebruiker klikt op OK waarna een middels een panel een bevestiging wordt gevraagd. De machtiging is ingetrokken. De derde kan via het overzicht in Mijn Portaal de intrekking machtiging inzien 3 Een derde is altijd iemand die ook een account heeft in DVKI Pagina 24