BILAG 2 KRAVSPECIFIKATION

4. februar 2011 BILAG 2 KRAVSPECIFIKATION KOMBIT A/S Halfdansgade 8 2300 København S www.kombit.dk

Indholdsfortegnelse 1. Vejledning til Leverandøren... 4 1.1 Kravspecifikationens indhold... 4 1.2 Om selve kravspecifikationen... 4 1.3 Besvarelse af kravspecifikationen... 5 2. Baggrund... 6 2.1 Kort om Kunden... 6 2.2 Forretningsbehov for fremtidig infrastruktur... 7 2.3 Løsningsarkitektur for fremtidig infrastruktur... 8 2.4 Overordnede arkitekturprincipper for fremtidig infrastruktur... 9 2.5 Arkitekturkomponenter til fremtidig infrastruktur... 9 3. Løsningen... 11 3.1 Løsningens arkitektur og funktionalitet... 11 3.2 CPR-data... 12 3.3 Use cases til Løsningen... 13 3.4 Overordnede arkitekturprincipper... 13 3.5 Arkitekturkomponenter... 14 3.6 It-miljøer... 15 4. Funktionelle behov... 16 4.1 Use case A1: Foretag registerudtræk fra CPR-registret... 17 4.2 Use case A2: Foretag registerændringsudtræk fra CPR-registret... 19 4.3 Use case A3: Overfør udtræk... 21 4.4 Use case B1: Indlæsningsformater... 23 4.5 Use case B2: Udstil metadata... 24 4.6 Use case B3: Validering og sikring af datakvalitet... 24 2

4.7 Use case B4: Udtræk af logningsinformation... 26 4.8 Use case B5: Udtræk af forbrugsinformation... 27 4.9 Use case B6: Administrer services... 27 4.10 Use case B7: Driftsovervågning... 28 4.11 Use case B8: Administrer og afsend ændringsadviseringer... 29 4.12 Use case B9: Persistering (lagring) af data... 30 5. Non-funktionelle krav... 32 5.1 Arkitekturprincipper... 32 5.2 Sikkerhed... 33 5.3 Vedligeholdelse og videreudvikling... 34 5.4 Portabilitet... 34 5.5 Effektivitet og skalering... 35 5.6 Pålidelighed og tilgængelighed... 35 6. Relaterede ydelser... 37 6.1 Dokumentation... 37 6.2 Etablering og drift af test- og udviklingsmiljø... 39 6.3 Overdragelse... 41 6.4 Servicemål til Driftsprøve... 42 3

1. Vejledning til Leverandøren Dette bilag udgør Kundens kravspecifikation til Løsningen og relaterede ydelser, herunder dokumentation, drift samt servicemål. Dermed udgør dette bilag i sammenhæng med underbilag 2A, Leverandørens beskrivelse af Løsningen og relaterede ydelser, og underbilag 2B, Behovs- og kravsopfyldelse, den samlede beskrivelse af Løsningen og relaterede ydelser. Leverandøren skal ikke udfylde dette bilag, men besvare bilaget gennem udfyldelse af underbilag 2A, Leverandørens beskrivelse af Løsningen og relaterede ydelser, og underbilag 2B, Behovs- og kravsopfyldelse. 1.1 Kravspecifikationens indhold Bilaget er udformet som følger. Afsnit 1 er en kort beskrivelse af indholdet af bilag 2 og underbilagene til dette, samt hvordan Leverandøren udfylder disse. Afsnit 2 er et baggrundsafsnit, der kort introducerer Kunden og Kundens behov for en fremtidig infrastruktur. Dette afsnit er alene baggrundsviden og beskriver ikke Løsningen, der skal leveres under Kontrakten. Afsnit 3 beskriver på et overordnet niveau, hvad Løsningen består af, hvilken kontekst den skal indgå i, og hvilke forventninger Kunden har til funktionalitet og arkitektur. Afsnit 4 angiver Kundens funktionelle behov til Løsningen. Afsnit 5 angiver Kundens non-funktionelle krav til Løsningen. Afsnit 6 angiver Kundens krav til relaterede ydelser, herunder dokumentation, drift og vedligehold, samt servicemål Kravspecifikationen er udformet med vekslende tekstuel beskrivelse af behov og krav og de relevante behov og krav. 1.2 Om selve kravspecifikationen Der skelnes mellem behov og krav. I det følgende listes de anvendte typer behov og krav. Behov er defineret ved nedenstående typer. Behovsprioritet Betegnelse Beskrivelse Høj Behov.Høj Det pågældende behov har høj prioritet og vurderes at være nødvendigt for Løsningen. Almindelig Behov.Alm Det pågældende behov har almindelig prioritet og vurderes at være ønskværdig men ikke nødvendig for Løsningen. Leverandørens opfyldelse af behov med høj prioritet vægtes højere end opfyldelse af behov med almindelig prioritet. Der er ingen behov, som skal opfyldes for, at Leverandørens tilbud er konditionsmæssigt. 4

Kan Leverandøren eller dennes løsning delvis imødekomme det pågældende behov, angives Delvist opfyldt. Angives Delvist opfyldt, vurderes dette som et forbehold og Leverandøren skal i kommentarfeltet specificere, hvad forbeholdet for behovets opfyldelse omfatter. Hvis ikke Leverandøren indsætter en kommentar vurderes behovet som Ikke opfyldt. Krav er defineret ved nedenstående typer. Kravs type Betegnelse Kravs opfyldelse Mindstekrav Krav.Min Leverandøren skal opfylde dette krav. Manglende opfyldelse eller delvis opfyldelse vil betyde, at tilbuddet ikke er konditionsmæssigt. Krav Krav.Alm Leverandøren skal i udgangspunktet opfylde dette krav og leverandørens opfyldelse af kravet indgår i vægtning af Leverandørens tilbud. Manglende eller delvis opfyldelse vil ikke betyde, at tilbuddet er ukonditionsmæssigt, men vil tælle ned i bedømmelsen af Leverandørens tilbud. De krav som Kunden finder uundværlige for Løsningen, har prioritet af Mindstekrav. De almindelige krav er væsentlige for Løsningen, men ikke nødvendige. Kan Leverandøren eller dennes løsning delvis imødekomme det pågældende krav, angives Delvist opfyldt. Angives Delvist opfyldt, vurderes dette som et forbehold og Leverandøren skal i kommentarfeltet specificere, hvad forbeholdet for kravets opfyldelse omfatter. Hvis ikke Leverandøren indsætter en kommentar vurderes kravet som Ikke opfyldt. Alle krav er angivet med et fortløbende nummer. 1.3 Besvarelse af kravspecifikationen Leverandøren besvarer kravspecifikationen ved at udfylde underbilag 2A, Leverandørens beskrivelse af Løsningen og relaterede ydelser, og underbilag 2B, Behovs- og kravsopfyldelse I underbilag 2A skal Leverandøren vise, hvordan dennes løsning lever op til Kundens behov og krav. En vejledning om udarbejdelse findes i underbilaget. I underbilag 2B skal Leverandøren angive, i hvilket omfang dennes løsning opfylder Kundens behov og krav som vist i skemaet nedenfor. En vejledning om udarbejdelse findes ligeledes i underbilaget. 5

2. Baggrund I dette afsnit præsenteres Kunden og Kundens vision for en fremtidig infrastruktur. Det skal bemærkes, at den fremtidige infrastruktur ikke er en del Kontrakten. Løsningen, der skal leveres under Kontrakten, er et Proof of Concept for den fremtidige infrastruktur. Formålet med dette Proof of Concept er at opbygge erfaringer hos Kunden i etablering af en fremtidssikret infrastruktur. Omfanget af Løsningen under Kontrakten er beskrevet i afsnit 3 og behovs- og kravspecificeret i afsnit 4, 5 og 6. Formålet med dette afsnit er alene at give Leverandøren indblik i Kundens vision for en fremtidig infrastruktur, således at Leverandøren kan bidrage til, at levering af Løsningen skaber de nødvendige erfaringer hos Kunden. Intet i dette afsnit er krav eller vil blive tillagt vægt i forbindelse med vurdering af Leverandørens tilbud. 2.1 Kort om Kunden KOMBIT A/S (herefter Kunden) er et kommunalt aktieselskab, som er 100 % ejet af Kommunernes Landsforening (KL). Kunden har til formål at arbejde for at sikre et bredt udvalg af effektive og innovative løsninger til gavn for den kommunale opgaveløsning. Kunden har i den forbindelse bl.a. igangsat en række projekter vedrørende indkøb af udvikling af nye it-løsninger, der stilles til rådighed for danske kommuner. Særligt væsentligt for Løsningen, der skal leveres under Kontrakten, er, at Kunden har iværksat et projekt om at skaffe kommunerne billigere og nemmere adgang til data. Baggrunden for projektet er, at kommunerne ofte har vanskeligt ved at få adgang til egne data. Det medfører ofte uforholdsmæssigt store omkostninger for kommunerne enten i form af direkte udgifter, eller fordi det simpelthen ikke er muligt for den enkelte kommune at udnytte potentielle gevinster ved it. Det skyldes, at adgang til data fra både basis- og fagsystemer i høj grad er vanskeliggjort af, at leverandørerne af fagsystemer sjældent samarbejder om at stille relevante data til rådighed. Dertil kommer, at den manglende konkurrence gør data uforholdsmæssigt dyre for såvel den enkelte kommune, der ønsker at løse sine opgaver smartere og for den enkelte leverandør, der ønsker at forbedre eksisterende løsninger eller udvikle helt nye løsninger. Dette reducerer mulighederne for nødvendige effektiviseringsgevinster i kommunerne. 1 1 For yderligere information henvises til www.kombit.dk. 6

Figur 1 Den nuværende situation i forbindelse med adgang til data fra registre. 2.2 Forretningsbehov for fremtidig infrastruktur En central forudsætning for projektet er, at der etableres en infrastruktur. Dels for at understøtte adgang til relevante data, dels for at udgøre en fælles infrastruktur for en række it-løsninger hos Kunden og for kommunerne. I den sammenhæng er det særligt relevant, at infrastrukturen kan understøtte selvbetjeningsløsninger og håndtering af fælleskomponenter. Selvbetjeningsløsninger Kunden skal etablere it-løsninger, der tilbyder kommunale medarbejdere, borgere og virksomheder adgang til selvbetjeningsløsninger, med adgang til relevante kildesystemer og registre. Dette vil kun være muligt såfremt, der etableres en infrastruktur, som anvender generelle softwarekomponenter til præsentation, forretningslogik og persistering af data. I den sammenhæng skal en række tværoffentlige og eksterne services endvidere understøttes (udenfor infrastrukturen). Eksempler på tværoffentlige services kunne være Dokumentboks og Printservice. Eksempler på eksterne services kunne være adgang til basisregistre, som CPR- eller CVR-registret. Desuden vil der være behov for at anvende infrastrukturkomponenter til fx logning, katalog over services, mv. Fælleskomponenter Fælleskomponenter udviklet af både Kunden og eksterne parter, fx kommuner, skal kunne udstilles (forudsat, at forretningslogik og teknologi er kompatibel med infrastrukturen). Denne tværkommunale anvendelse forudsætter portalsupport, brugerstyring, mv. af infrastrukturen. 7

2.3 Løsningsarkitektur for fremtidig infrastruktur For at imødekomme de skitserede forretningsbehov skal den fremtidige infrastruktur muliggøre: Aggregering og integration af data fra forskellige kildesystemer. Forskellige anvendere kan herefter tilgå disse data. Udstilling af fælleskomponenter, fælles brugergrænseflader og generelt understøttelse af it-projekter hos Kunden. Håndtering af sikkerhed. Eksempelvis må det i forbindelse med selvbetjeningsløsninger forventes, at NemID og Digital Signatur skal anvendes, og al adgang skal logges. Infrastrukturen skal være i stand til at generere forbrugsinformationer til at understøtte forskellige afregningsmodeller. Det vil sige, at data om infrastrukturens brug skal opsamles løbende, så forskellige modeller kan understøttes. Overvågning af drift. Figur 2 illustrerer den overordnede arkitektur for den fremtidige infrastruktur. Figur 2 Løsningskoncept. Her fremgår det, at infrastrukturen indtager en central position mellem registre og anvendersystemer (fx en selvbetjeningsløsning i en kommune). Infrastrukturen udbyder sine services via et service katalog, sikrer tilgængeligheden via løbende overvågning, og afregner efter en afregningsmodel, der skal defineres nærmere. 8

2.4 Overordnede arkitekturprincipper for fremtidig infrastruktur Den fremtidige infrastruktur forventes at være baseret på modne teknologier, helst standardkomponenter og Open Source og i øvrigt underlagt OIO-hvidbogens arkitekturprincipper 2. 2.5 Arkitekturkomponenter til fremtidig infrastruktur I tillæg til ovenstående arkitekturprincipper forventes den fremtidige infrastruktur baseret på en lagdelt, service-baseret arkitektur. Nedenfor er en skitse for en sådan lagdelt, service-baseret arkitektur Figur 3 Udkast til lagdelt arkitektur. Som Figur 3 illustrerer, tænkes i følgende lag: Systemadgang, der er ansvarlig for at give adgang til udtræk eller til systemer. Disse systemer har egne grænseflader, hvorfor adaptere 3 skal anvendes for tilgang til disse systemer. Servicekomponenter, der er genbrugelige komponenter, der anvendes i alle de services, der udstilles via platformen, fx til brugerstyring, logning, og sikkerhed. Data integration og service implementering, der er ansvarlig for at definere en standardiseret datamodel og standardiserede grænseflader. Enterprise service bus, der udstiller services og styrer adgangen til disse. 2 http://www.itst.dk/it-arkitektur-og-standarder/it-arkitektur/om-arkitektur/baggrund-for-oioarkitekturarbejdet/hvidbog-om-it-arkitektur/hvidbog_om_it-arkitektur.pdf 3 Adaptere er integrationskomponenter der tillader adgang fra et system til et andet, og hvor adgangen kræver tilpasning. Dette kan fx være en database adapter, der giver adgang til forskellige databaser, og hvor umiddelbare forskelle i de underliggende databaser skjules for anvenderen af adapteren. 9

Forretningslag, hvor serviceorkestrering, hændelseshåndtering, regelhåndtering og monitorering håndteres, samt eventuelle brugergrænseflader udstilles. 10

3. Løsningen I dette afsnit præsenteres selve Løsningen, der skal leveres under Kontrakten. Løsningen, der skal leveres under Kontrakten, er som beskrevet i indledningen af afsnit 2, et Proof of Concept for den fremtidige infrastruktur. Det betyder, at det væsentligste formål med Løsningen er at opbygge erfaringer hos Kunden i etablering af en større infrastruktur. Det har tre væsentlige konsekvenser i forhold til omfanget af Løsningen og relaterede ydelser under Kontrakten. 1) Løsningen skal ikke anvendes i produktion. 2) Løsningen er midlertidig og skal kun være i drift i tidsrummet mellem en gennemført funktionel overtagelsesprøve og en gennemført driftsprøve (jf. bilag 1, Tidsplan). Driftsperioden forventes derfor alene at vare cirka 4 uger. 3) Løsningen er funktionelt begrænset i omfang i forhold til Kundens vision om en fremtidig infrastruktur, jf. afsnit 2. I dette afsnit præsenteres en tekstuel beskrivelse af Løsningen og relaterede ydelser, der skal leveres under Kontrakten. De konkrete behovs- og kravsopgørelser fremgår af afsnit 4, 5 og 6. I forhold til den fremtidige infrastruktur har Løsningen, som beskrevet ovenfor, et reduceret omfang. Ikke desto mindre ønsker Kunden, at: - Løsningens værdi kan afprøves. Derfor ønsker Kunden, at Løsningen skaber adgang til et konkret dataområde, og at dette dataområde igen kan stilles til rådighed for et it-system hos Kunden. Til formålet skal anvendes CPR-data. En beskrivelse af CPR-data gives i underafsnit 3.2. - Løsningen baserer sig på en række af de arkitekturprincipper, som Kunden forventer at bygge den fremtidige infrastruktur på. Kundens forventninger til arkitektur, funktionalitet, mv. gennemgås i underafsnit 3.3, 3.4, 3.5 og 3.6. De konkrete behov og krav fremgår af afsnit 4 og 5. Indledningsvist gennemgås Kunden overordnede forventninger til Løsningens arkitektur og funktionalitet. 3.1 Løsningens arkitektur og funktionalitet Overordnet forventer Kunden, at: Løsningen kan foretage registerudtræk og registerændringsudtræk af CPR-data fra CPR-registret Løsningen kan lagre udtrukne CPR-data på en måde, der sikrer, at Løsningen lagrer et aktuelt totaludtræk Løsningen kan udstille lagrede CPR-data på sikker og standardiseret vis, herunder som OIOXML Kunden kan efter behov hente parameterbestemte udtræk af CPR-data fra Løsningen under overholdelse af krav til sikkerhed, mv. 11

Løsningen adviserer automatisk om ændringer i lagrede CPR-data på specificerede intervaller, fx ugentligt Løsningen etableres i et udviklingsmiljø og et testmiljø hos Leverandøren, som Leverandøren skal drifte, indtil Driftsprøven er gennemført. Nedenstående figur viser løsningsarkitekturen for Løsningen. Her fremgår det, at figuren er en begrænset version af Figur 2 Løsningskoncept., underafsnit 2.3. Figur 4: Omfanget af Løsningen. Funktionalitet inkluderer Logning, overvågning og forbrugsmåling til afregning, samt et servicekatalog og basal sikkerhed. Dertil kommer funktionalitet til selve CPR-servicen. Der forventes ikke brugerstyring. 3.2 CPR-data I dette underafsnit gives en tekstuel beskrivelse af, hvordan Løsningen skal tilgå og stille CPR-data til rådighed. De konkrete behov til dette fremgår af afsnit 4. CPR-data vil blive gjort tilgængelige på CPRs-dataserver som udtræk. Denne understøtter sikker FTP-forbindelse, SSH og Netview FTP 4. Til Løsningen anvendes sikker FTP (RFC 4217). CPR-registret udstiller både fulde registerudtræk og registerændringsudtræk, der kan hentes fra deres server 5. Data kan udtrækkes i et format med records af forskellige typer med faste feltbredder. 4 Levering af data, på siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4107, Testdata til udtræk, på siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4188, samt specifikt om filtransmission her: http://www.cpr.dk 5 Jf. http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4107, Testdata til udtræk, på siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4188, samt specifikt om filtransmission her: 12

Løsningen skal følgelig være i stand til aktivt at hente et registerudtræk til etablering af et totaludtræk af CPR-data. Derudover skal Løsningen aktivt og skeduleret kunne hente registerændringsudtræk til opdatering af totaludtrækket af CPR-data. Derved forbliver totaludtrækket aktuelt. Så snart et registerudtræk eller registerændringsudtræk er hentet, skal Løsningen udstille et totalsæt af aktuelle CPR-data til et it-system hos Kunden. Kunden henter på den baggrund relevante data. I forbindelse med Løsningen forventes det, at et udtræk fra en enkelt kommune anvendes (maksimum 50.000 personer). 3.3 Use cases til Løsningen I dette underafsnit gives en tekstuel beskrivelse af de use cases, der udgør de funktionelle behov til Løsningen. De konkrete funktionelle behov fremgår af use casene i afsnit 4. Nedenstående figur viser relevante use cases til løsningsarkitekturen. Figur 5 Oversigt over use cases. I navngivningen af use casene anvendes enten A eller B, hvor: A indikerer, at der indgår andre aktører end Løsningen selv. B indikerer, at det primært er Løsningen selv, der er aktøren. 3.4 Overordnede arkitekturprincipper Som nævnt ovenfor ønsker Kunden, at Løsningen baserer sig på en række af de arkitekturprincipper, som Kunden forventer at bygge den fremtidige infrastruktur på. Nedenfor http://www.cpr.dk; u12180-p pnr nøgler off valgfrie recordtyper.pdf, tilgængelig fra siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4270; Jf. u12170-p ændringsudtræk off valgfrie recordtyper.pdf, tilgængelig fra siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4270 13

gives en tekstuel beskrivelse af de arkitekturprincipper, som Løsningen skal bygge på. De konkrete krav til arkitektur fremgår af underafsnit 5.1. Funktionalitet bør udstilles som services. Dette inkluderer også hændelsesadviseringer. Services skal være indkapslet, således at et anvendersystem af en service ikke skal være bekendt med, hvordan servicen er implementeret for at anvende den. Løsningen skal være fleksibel, således at den kan interagere og samarbejde med andre systemer. Løsningen skal understøtte relevante fællesoffentlige standarder, herunder OIOgodkendte standarder. I det omfang yderligere standarder er relevante, skal de ligeledes anvendes. Løsningen skal i videst mulig omfang anvende modne teknologier. Det vil sige, at afprøvede komponenter foretrækkes frem for nyere. Komponenter baseret på open source-licens foretrækkes frem for kommercielle komponenter. 3.5 Arkitekturkomponenter Nedenfor gives en tekstuel beskrivelse af, hvilke arkitekturkomponenter der skal indgå i Løsningen. En fuldstændig behovsopgørelse fremgår af afsnit 4. Løsningen er begrænset i omfang i forhold til, hvad der tænkes i den fremtidige infrastruktur. Enkelte af de arkitekturkomponenter, der forventes at skulle indgå i en fremtidig infrastruktur, skal imidlertid også indgå i Løsningen. Nedenfor illustreres de konkrete arkitekturkomponenter, der tænkes realiseret til Løsningen. Komponenterne udgør en delmængde af de komponenter, der fremgår af Figur 3 Udkast til lagdelt arkitektur. Komponenter markeret med X indgår ikke i Løsningen. Figur 6 Forventede arkitekturkomponenter i Løsningen. 14

Der skal realiseres en CPR-service og en CPR-datamodel. Dertil kommer, at der skal anvendes adaptere for at kunne tilgå udtræk fra CPR. Den udviklede service skal udstilles i et servicekatalog. Det forventes også, at en portal er relevant i forbindelse med administration. Løsningen skal kunne advisere Kunden om ændringer, hvilket kræver en basal hændelseshåndtering. Desuden skal basale informationer logges for at tillade basal overvågning samt datagrundlag for afregning. Endeligt skal der være basal sikkerhed. 3.6 It-miljøer Nedenfor gives en tekstuel beskrivelse af, hvilke it-miljøer der skal indgå i Løsningen. De konkrete krav til it-miljøer fremgår af afsnit 6.2 og 6.4. Kunden forventer, at Leverandøren etablerer nedenstående it-miljøer: Et fælles udviklingsmiljø, der kan anvendes til at udvikle Løsningen i. Dette miljø kendetegnes ved at være meget dynamisk, med få eller ingen processer for at sikre stabil drift. Et testmiljø, der udelukkende anvendes, når funktionalitet skal afprøves og i forbindelse med driftsprøve, jf. bilag 3, Prøver. Dette miljø kendetegnes ved at være mere kontrolleret. Der er defineret processer for, hvorledes testmiljøet håndteres, der primært retter sig imod, at ændringer sker eksplicit og styres af kvalitetssikringsfunktionen i udviklingen. 15

4. Funktionelle behov Krav til funktionalitet til Løsningen er i dette afsnit angivet som en behovsopgørelse. Behovsopgørelsen er struktureret omkring de use cases, der er identificeret i afsnit 3. Nonfunktionelle krav fremgår af afsnit 5. Først gives en vejledning til behovsopgørelsen og en introduktion til relevant terminologi, der skal anvende Løsningen, inden behovene til de enkelte use cases præsenteres. Vejledning til behovsopgørelsen I behovsopgørelsen angives de funktionelle behov til Løsningens understøttelse af de relevante use cases, som identificeret på Figur 5. For hver use case gives en overordnet beskrivelse samt en liste af identificerede behov, der er relateret til beskrivelsen. Beskrivelsen af hver use case følger denne struktur: Use casen beskrives tekstuelt. De mere komplekse use cases beskrives på struktureret form i en tabel med frekvens, startbetingelser, aktører, overordnet forløb, og slutbetingelser. I beskrivelsen af det overordnede forløb anvendes referencer til de konkrete behov. For use casene med flere aktører (A1, A2 og A3) er tillige et aktivitetsdiagram. Konkrete behov, der er identificeret i forbindelse med hver use case, angives med følgende to typer behovsprioritering: Behovsprioritet Betegnelse Beskrivelse Høj Behov.Høj Det pågældende behov har høj prioritet og vurderes at være nødvendigt for Løsningen. Almindelig Behov.Alm Det pågældende behov har almindelig prioritet og vurderes at være ønskværdig men ikke nødvendig for Løsningen. Leverandørens opfyldelse af behov med høj prioritet vægtes højere end opfyldelse af behov med almindelig prioritet. Der er ingen behov, som skal opfyldes for, at Leverandørens tilbud er konditionsmæssigt. Terminologi I såvel funktionelle behov og non-funktionelle og øvrige krav indgår nedenstående aktører. Rolle Beskrivelse Opgaver Anvendersystem Et eller flere it-systemer hos Kunden. Abonnerer på og udtrækker data fra Løsningen Administrator En fysisk bruger hos Kunden. Udfører administration i forbindelse med Løsningen. Tilgår ikke de data, Løsningen udstiller. CPR-registret CPR-registret eller anden Udstiller CPR-data til Løsningen af Kunden udpeget database med CPR-data. Driftsovervågning Repræsenterer et it- Overvåger løbende Løsningen og sik- 16

system, der er i stand til at overvåge Løsningen. rer, at den er operativ. I tillæg til aktørerne benyttes nedenstående begreber om udtræk. Udtrækstype Registerudtræk Registerændringsudtræk Totaludtræk (Øvrige) udtræk Beskrivelse Initielt dumpudtræk fra CPR-registret til Løsningen, jf. use case A1. Løbende udtræk af ændringer fra CPR-registret til Løsningen, jf. use case A2 Det samlede aktuelle sæt af CPR-data, der er tilgængelige i Løsningen. Beregnes på baggrund af registerudtræk og registerændringsudtræk, således at det afspejler de seneste CPR-oplysninger i CPR-registret. Alle udtræk fra Løsningen til Anvendersystemet. Udtræk kan udgøre en delmængde af totaludtrækket, samt forbrugs- og logningsinformation. 4.1 Use case A1: Foretag registerudtræk fra CPR-registret I denne use case skal Løsningen udtrække og lagre CPR-data, så data kan stilles til rådighed for Anvendersystemet. Desuden skal Anvendersystemet adviseres om ændringer i CPR-data. Løsningen skal altså understøtte registerudtræk fra CPR-registret, herunder at data fra dette registerudtræk lagres i Løsningen, samt understøtte advisering af Anvendersystemet. Use case A1 Foretag registerudtræk fra CPR-registret Formål Løsningen kan foretage registerudtræk fra et CPRregistret. Frekvens Dagligt eller på nærmere specificeret tidspunkt Startbetingelser Kunden har etableret en aftale om registerudtræk fra CPR-registret. Der kan eksistere tilmeldinger til adviseringer om ændringer i totaludtræk, jf. use case B8. Aktører Overordnet forløb Slutbetingelser Løsningen, CPR-registret, Anvendersystemet 1. Løsningen henter et registerudtræk fra CPRregistret (se Behov.Høj.01) 2. Der kvitteres for registerudtrækket (se Behov.Høj.01). 3. Registerudtrækket transformeres (normaliseres), indlæses og lagres i Løsningen (se Behov.Høj.02, Behov.Høj.03, og Behov.Høj.04). 4. Ændringer til totaludtræk beregnes (se Behov.Høj.05) 5. Anvendersystemer, der abonnerer på ændringer, adviseres om ændringer (se Behov.Høj.06). Løsningen har kvitteret for gennemført registerudtræk, adviseringer er overført, og det ny totaludtræk er udstillet til Anvendersystemet. 17

Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A1. CPR-registeret Løsningen Anvendersystem Overfør udtræk Hent udtræk Validering af modtagelse Modtag kvittering Send kvittering Normalisering af data Beregn ændringer Gem data og ændringer Dan nyt totaludtræk og ændringer Overfør advisering om ændringer Modtag advisering om ændringer Håndter advisering Gør udtræk tilgængeligt for opslag Håndter advisering Overfør advisering om ny totaludtræk Modtag advisering om nyt totaludtræk Figur 7 Use case A1: Modelskitse for registerudtræk fra CPR-registret til Løsningen. Som vist på Figur 7 foretager Løsningen et (nyt) registerudtræk fra CPR-registret. Løsningen validerer overførslen med en kontrol af, om overførslen er komplet, og om det grundlæggende format for overførslen er overholdt. Herefter må det forventes, at Løsningen skal kvittere for overførslen til CPR-registret. Løsningen foretager en transformation af data, således at Løsningen herefter håndterer data på en normaliseret (standardiseret) form. Baseret på den normaliserede form kan eventuelle ændringer til data beregnes, og disse ændringer lagres sammen med data i Løsningen. Herefter kan et nyt sæt totaldata Det vil sige den samlede datamængde for hele dataområdet dannes og gøres tilgængeligt for udtræk. Sideløbende med at gøre det samlede sæt totaldata tilgængeligt, kan adviseringer overføres. Behov, der beskriver hvordan ændringsadviseringer håndteres er beskrevet i use case B8. Følgende overordnede behov er tilknyttet use case A1. 18

Behov.Høj.01. Hente registerudtræk fra CPR-registret Løsningen kan hente et registerudtræk fra CPR-registret ved hjælp af sikker filoverførsel, og kan håndtere at kvittere for modtagelse. Behov.Høj.02. Validering af registerudtræk Løsningen kan automatisk validere, at et overført registerudtræk, der modtages af Løsningen, er overført korrekt, jf. use case B3. Behov.Høj.03. Indlæsning af registerudtræk Løsningen kan indlæse et registerudtræk fra CPR-registeret som en fil i Løsningen, jf. use case B1. Behov.Høj.04. Transformering i forbindelse med modtagelse af registerudtræk Løsningen kan transformere alle data i registerudtræk fra CPR-registret til en normaliseret form. Det samme gælder eventuelle metadata, der overføres i forbindelse med registerudtrækket. Løsningen skal understøtte, at transformationen benytter tabeller og algoritmer, og at disse kan lagres i Løsningen. Behov.Høj.05. Beregn ændringer i forhold til tidligere registerudtræk Løsningen kan på baggrund af tidligere modtagne registerudtræk automatisk beregne ændringer til totaludtræk. Behov.Høj.06. Advisering i forbindelse med modtagelse af registerudtræk Løsningen kan automatisk generere adviseringer om ændringer i totaludtrækket, og automatisk sende adviseringer til Anvendersystemet, der abonnerer på ændringer, jf. use case B8. 4.2 Use case A2: Foretag registerændringsudtræk fra CPR-registret Løsningen skal understøtte, at Løsningen modtager et registerændringsudtræk fra CPRregistret, og at relevante data lagres i Løsningen. I denne use case skal Løsningen på baggrund af ændringsudtrækket fra CPR-registret foretage en opdatering af det lagrede totaludtræk, så et aktuelt totaludtræk kan stilles til rådighed for Anvendersystemet. Desuden skal Anvendersystemet adviseres, hvis det har abonnement på ændringer. Use case A2 Foretag registerændringsudtræk fra CPR-registret Formål Løsningen kan foretage registerændringsudtræk fra CPRregistret. Frekvens Dagligt eller på nærmere specificeret tidspunkt Startbetingelser Kunden har etableret en aftale om registerændringsudtræk fra CPR.registret. Løsningen har tidligere indlæst et komplet registerudtræk fra CPR-registret, jf. use case A1. Der kan eksistere tilmeldinger til adviseringer om ændringer i totaludtrækket, jf. use case B8. Aktører Løsningen, CPR-registret, Anvendersystemet 19

Overordnet forløb Slutbetingelser 1. Løsningen henter et registerændringsudtræk fra CPR-registret (se Behov.Høj.07). 2. Der kvitteres for modtagelse af registerændringsudtrækket (se Behov.Høj.07). 3. Registerændringsudtrækket normaliseres (standardiseres), indlæses og lagres i Løsningen (se Behov.Høj.08, Behov.Høj.09, og Behov.Høj.10). 4. Registerændringsudtrækket anvendes til at generere et nyt totaludtræk (se Behov.Høj.11). 5. Hvis Anvendersystemet har abonnement på ændringer, adviseres det om ændringer i totaludtrækket(se Behov.Høj.12). Løsningen har kvitteret for modtagelse, adviseringer er overført, og et nyt totaludtræk er tilgængeligt for Anvendersystemet. Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A2. CPR-registeret Løsningen Anvendersystem Overfør opdatering Hent ændringer Validering af modtagelse Modtag kvittering Send kvittering Normalisering af ændringer Beregn samlet datasæt Gem data og ændringer Dan nyt totaludtræk og ændringer Overfør advisering om ændringer Modtag advisering om ændringer Håndter advisering Gør udtræk tilgængeligt for opslag Håndter advisering Overfør advisering om ny totaludtræk Modtag advisering om nyt totaludtræk Figur 8 Use case A2: Modelskitse for registerændringsudtræk fra CPR-registret til Løsningen. 20

Som vist på Figur 8 hentes et registerændringsudtræk til Løsningen fra CPR-registret. Løsningen validerer overførslen med en kontrol af, om overførslen er komplet, og om det grundlæggende format for overførslen er overholdt. Herefter må det forventes, at Løsningen skal kvittere for overførslen til CPR-registret. Løsningen foretager en transformation af data, således at Løsningen herefter håndterer data på en normaliseret og standardiseret form. Baseret på den normaliserede form kan det samlede nyt datasæt beregnes, og dette lagres sammen med ændringer i Løsningen. Herefter kan et nyt sæt totaldata Det vil sige den samlede datamængde for hele dataområdet dannes og gøres tilgængeligt for udtræk. Sideløbende med at gøre det ny totaludtræk tilgængeligt, kan adviseringer overføres. Behov til hvordan ændringsadviseringer håndteres er beskrevet i use case B8. Følgende overordnede behov er tilknyttet use case A2. Behov.Høj.07. Hente ændringsudtræk fra CPR-registret (CPR) Løsningen kan hente et ændringsudtræk fra CPR-registret ved hjælp af sikker filoverførsel og kan kvittere for modtagelse. Behov.Høj.08. Validering af registerændringsudtræk Løsningen kan automatisk validere, at et registerændringsudtræk modtaget af Løsningen er korrekt overført, jf. use case B3. Behov.Høj.09. Indlæsning af registerændringsudtræk Løsningen kan indlæse et registerændringsudtræk fra CPR-registret som en fil i Løsningen, jf. use case B1. Behov.Høj.10. Transformering i forbindelse med modtagelse af registerændringsudtræk Løsningen kan transformere et registerændringsudtræk fra CPR-registret til en normaliseret form. Det gælder også eventuelle metadata modtaget i forbindelse med registerændringsudtrækket. Løsningen skal understøtte, at transformationen benytter tabeller og algoritmer, og at disse kan lagres i Løsningen. Behov.Høj.11. Beregn samlet totaludtræk Løsningen kan beregne et nyt totaludtræk på baggrund af registerændringsudtrækket og det nuværende totaludtræk. Behov.Høj.12. Advisering i forbindelse med modtagelse af registerændringsudtræk Løsningen kan automatisk generere adviseringsdokumenter om ændringer i totaludtræk og automatisk sende adviseringer til Anvendersystemet, hvis det abonnerer på ændringer, jf. use case B8. 4.3 Use case A3: Overfør udtræk Løsningen skal understøtte overførsel af CPR-data fra Løsningens totaludtræk til Anvendersystemet. Dette kan både ske på Anvendersystemets egen opfordring, og som konsekvens af, at Anvendesystem er blevet adviseret om ændringer i totaludtrækket lagret i Løsningen. Det skal således være muligt for Anvendersystemet både at modtage samtlige CPR-data i Løsningen og en delmængde heraf, herunder ændringer i forhold til seneste overførsel af CPR-oplysninger fra Løsningen til Anvendersystemet. I denne use case skal Løsningen altså kunne håndtere en anmodning fra Anvendersystemet og på den baggrund på effektiv vis overføre data til Anvendersystemet. 21

Use case A3 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Overfør udtræk Anvendersystemet kan konfigurere og hente et nærmere specificeret udtræk fra Løsningens totaludtræk. Dagligt eller på nærmere specificeret tidspunkt Løsningen lagrer et komplet, aggregeret totaludtræk fra CPR-registret, jf. use case A1 og A2. Løsningen, Anvendersystemet 1. Anvendersystemet anmoder om et udtræk af data (se Behov.Høj.13). 2. Anmodningen indeholder eventuelt parametre (se Behov.Høj.16 og Behov.Høj.17). 3. Løsningen modtager anmodningen (se Behov.Høj.13). 4. Løsningen forbereder og overfører udtrækket til Anvendersystemet (se Behov.Høj.14 og Behov.Høj.15). Det ønskede udtræk er overført til Anvendersystemet. Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A3. Løsningen Anvendersystem Modtag anmodning Anmod om udtræk Klargør udtræk til forsendelse Log til afregning m.m. Send udtræk Modtag udtræk Håndter udtræk Figur 9 Use case A3: Modelskitse for overførsel af udtræk fra Løsningen til Anvendersystemet. Som vist på Figur 9 sender Anvendersystemet en anmodning om et udtræk til Løsningen. Løsningen modtager anmodningen om udtrækket og forbereder herefter udtrækket til forsendelse, inden det sendes til Anvendersystemet. Samtidig hermed logges informationer om adgangen til data, samt forbrugsinformationer til en eventuel afregning. Følgende overordnede behov er tilknyttet use case A3. 22

Behov.Høj.13. Anmodning om overførsel af udtræk Løsningen kan modtage en anmodning om overførsel af et udtræk fra Anvendersystemet. Behov.Høj.14. Overførsel af udtræk Løsningen kan 1) automatisk overføre det udtræk, Anvendersystemet anmoder om, og 2) understøtte, at Anvendersystemet selv kan hente det udtræk, Løsningen har stillet til rådighed efter en anmodning om overførsel. Behov.Høj.15. Format for udtræk Løsningen understøtter, at udtræk kan foretages som flad, kommasepareret fil, samt i struktureret form ved den seneste version af OIO-XML. Behov.Høj.16. Udtræksparametre I forbindelse med overførsel af et udtræk fra Løsningen til Anvendersystemet tillader Løsningen, at Anvendersystemet på en let tilgængelig måde kan konfigurere udtræksparametre til at specificere, hvilke dele af udtrækket der skal udtrækkes og i hvilket format. Det er her særligt relevant at kunne udtrække data på baggrund af ændringsadvisering, jf. use case B8. Behov.Høj.17. Konfiguration af udtræksparametre Løsningen tillader, at Anvendersystemet kan konfigurere udtræksparametre således, at disse automatisk tages i betragtning, uden at disse eksplicit inkluderes i anmodningen. 4.4 Use case B1: Indlæsningsformater Det er centralt for registerudtræk fra CPR-registret, at Løsningen er i stand til at indlæse data fra registerudtrækket, samt behandle og lagre dem i en normaliseret repræsentation. Løsningen skal derfor være i stand til at indlæse data fra CPR-registret. Use case B1 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Indlæsningsformater Løsningen er i stand til at indlæse alle data ved registerudtræk og registerændringsudtræk fra CPR-registret. Dagligt eller på nærmere specificeret tidspunkt Data fra CPR-registret er tilgængelige for Løsningen, jf. use case A1 og A2. Løsningen Ved passende konfiguration af Løsningen kan data indlæses i Løsningen før videre behandling (se Behov.Høj.18, og Behov.Høj.19). Data er indlæst i Løsningen. Følgende overordnede behov er tilknyttet use case B1. Behov.Høj.18. Indlæsning af registerudtræk Løsningen kan indlæse registerudtræk fra CPR-registeret, jf. specifikationen 6. Behov.Høj.19. Indlæsning af registerændringsudtræk Løsningen kan indlæse registerændringsudtræk fra CPR-registeret 7. 6 Jf. u12180-p pnr nøgler off valgfrie recordtyper.pdf, tilgængelig fra siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4270. 7 Jf. u12170-p ændringsudtræk off valgfrie recordtyper.pdf, tilgængelig fra siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4270. 23

4.5 Use case B2: Udstil metadata Det er væsentligt, at informationer om data (metadata) udstilles på Løsningen. Som minimum udgøres metadata af information om dataaktualitet (hvor nye er data, hvornår er de sidst opdaterede), samt hvilken kilde der har leveret data. Metadata stilles til rådighed for Anvendersystemet gennem Løsningens udstillede grænseflader, jf. use case B6, samt i de udtræk, der leveres til Anvendersystemet, jf. use case A3. Use case B2 Udstil metadata sammen med data Formål Anvendersystemet kan hente metadata om de data, som det tilgår via Løsningen. Frekvens I forbindelse med modtagelse af registerudtræk og registerændringsudtræk fra CPR-registret. Startbetingelser At data indlæses fra CPR-registret, jf. use case A1 og A2. Aktører Løsningen Overordnet forløb 1. Løsningen modtager et registerudtræk eller et registerændringsudtræk, der inkluderer metadata (se Behov.Høj.20, Behov.Alm.01). 2. I forbindelse med modtagelsen dannes automatisk visse metadata (se Behov.Alm.04). 3. Ved udtræk af Anvendersystemet returneres relevante metadata, der er lagret sammen med udtræksdata (se Behov.Alm.02 og Behov.Alm.03). Slutbetingelser Metadata er sammen med data leveret til Anvendersystemet. Følgende overordnede behov er tilknyttet use casen. Behov.Høj.20. Metadata kan modtages i forbindelse med modtagelse af registerudtræk eller registerændringsudtræk Løsningen kan modtage metadata sammen med registerudtræk og registerudtræksdata, jf. use case A1 og A2. Behov.Alm.01. Metadata kan lagres i Løsningen Løsningen kan normalisere og lagre metadata, således at metadata kan tilbydes Anvendersystemet sammen med data til udtræk. Behov.Alm.02. Dataaktualitet indgår i udstillede services Løsningen understøtter, at informationer om aktualitet af data og kilde indgår i dens udstillede services. Behov.Alm.03. Dataaktualitet indgår i leverede data Løsningen understøtter, at informationer om aktualitet af data og kilde indgår i de data, der leveres til Anvendersystemet. Behov.Alm.04. Metadata dannes automatisk af Løsningen Løsningen danner automatisk visse metadata i forbindelse med håndtering af data, herunder tidsstempler for modtagelse af registerudtræk, og identifikation af datakilde. 4.6 Use case B3: Validering og sikring af datakvalitet Løsningen skal i forbindelse med modtagelse og håndtering af data sikre, at datakvaliteten er tilstrækkelig. Dette inkluderer validering af, at modtagelsen af registerudtræk og 24

registerændringsudtræk sker korrekt, at modtagne data er formateret korrekt, og at indholdet er korrekt. Use case B3 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Validering og sikring af datakvalitet Sikre, at de data, der indlæses i Løsningen, er af tilstrækkelig kvalitet. I forbindelse med modtagelse af registerudtræk og registerændringsudtræk fra CPR-registret. At data fra CPR-registret er overført, jf. use case A1 og A2. Løsningen 1. Løsningen kontrollerer, at det overførte registerudtræk eller registerændringsudtræk er overført helt. Det vil sige, at der ikke mangler data (se Behov.Høj.21, Behov.Høj.24 og Behov.Høj.25). 2. Løsningen kontrollerer, at registerudtrækket eller registerændringsudtrækket overholder formatspecifikationerne for CPR-data (se Behov.Høj.22, Behov.Høj.24 og Behov.Høj.25).. 3. Løsningen kontrollerer, at data i registerudtrækket eller registerændringsudtrækket overholder dataspecifikationerne for CPR-data (se Behov.Høj.23, Behov.Høj.24 og Behov.Høj.25).. Modtagne registerudtræk og registerændringsudtrækket er valideret og kan indlæses, jf. use case B1. Følgende overordnede behov er tilknyttet use case B3. Behov.Høj.21. Validering af dataoverførsel Løsningen understøtter specifikation og effektuering af en valideringsmekanisme, der kontrollerer, at et registerudtræk eller registerændringsudtræk, som hentes fra CPR-registret, er korrekt overført. Dette kan fx realiseres ved at anvende checksum eller kontrol af særlige markører (slutrecords) i data. Behov.Høj.22. Validering af dataformat Løsningen understøtter specifikation og effektuering af en valideringsmekanisme, der kontrollerer, at det specificerede dataformat for et registerudtræk eller registerændringsudtræk er overholdt. Dette kan fx realiseres ved at anvende viden om dataformatet til at kontrollere, at formatet er syntaktisk overholdt. Behov.Høj.23. Validering af dataindhold Løsningen understøtter specifikation og effektuering af en valideringsmekaniske, der kontrollerer, at modtagne data er indholdsmæssigt korrekte, herunder at en angivet dato faktisk er en korrekt dato (fx overholder antal dage i den pågældende måned). 25

Behov.Høj.24. Validering af CPR-formatet Løsningen kan validere, at dataformat er som specificeret 8 med hensyn til korrekt overførsel, format og dataindhold i forbindelse med modtagelse af registerudtræk og registerændringsudtræk fra CPR-registret. Behov.Høj.25. Håndtering af valideringsproblemer Løsningen understøtter konfiguration af, hvordan problemer i forbindelse med validering håndteres. I udgangspunktet skal Løsningen understøtte, at registerudtrækket eller registerændringsudtrækket ikke opfattes som korrekt overført, hvis valideringen fejler. 4.7 Use case B4: Udtræk af logningsinformation Løsningen skal kunne udtrække de informationer, der er logget af Løsningen. Løsningen foretager logning af adgang til data i forbindelse med fx opslag, udtræk, anmodninger, mv. for at sikre krav til sikkerhed. Løsningens logning skal være robust og i et format, der kan eksporteres. Behandling af informationerne foretages i et eksternt system. Use case B4 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Udtræk af logningsinformation At logningsinformation fra Løsningen kan gennemses og behandles i et eksternt system. Dagligt eller på nærmere specificeret tidspunkter Løsningen udstiller udtræk til Anvendersystemet, jf. use case A1, A2 og A3. Løsningen 1. Løsningen logger og lagrer opslag, modtagelse af registerudtræk og registerændringsudtræk, overførsel af udtræk, mv. (se Behov.Høj.26). 2. Løsningen genererer et udtræk af logningsinformationer, og gør udtrækket tilgængeligt for eksterne systemer (se Behov.Høj.27). Logningsudtræk kan inspiceres og indlæses i andre systemer hos Kunden. Følgende overordnede behov er tilknyttet use case B4. Behov.Høj.26. Datagrundlag for logning Løsningen skal logge alle relevante informationer om adgang til udstillede data, særligt med henblik på at sikre adgangslogning i forbindelse med krav til sikkerhed, og logning i forbindelse med Løsningens effektivitet. Behov.Høj.27. Udtræk af logningsinformationer Løsningen kan generere et udtræk af logningsinformationer fra Løsningen og stille det til rådighed for Anvendersystemet. Løsningen understøtter, at Anvendersystemet selv henter logningsinformationer, der er gjort tilgængelige via Løsningen. Logningsinformation skal være i gængse maskinlæsbare formater, fx som kommaseparerede fil. 8 Jf. u12180-p pnr nøgler off valgfrie recordtyper.pdf, tilgængelig fra siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4270. og u12170-p ændringsudtræk off valgfrie recordtyper.pdf, tilgængelig fra siden http://cpr.dk/cpr/site.aspx?p=64&t=visartikel&articleid=4270. 26

4.8 Use case B5: Udtræk af forbrugsinformation Løsningen skal kunne udtrække forbrugsinformationer, der er logget af Løsningen med henblik på afregning. Løsningen skal udelukkende levere datagrundlaget. Selve afregningen foretages i et eksternt system. Use case B5 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Udtræk af forbrugsinformation At forbrugsinformation fra Løsningen kan gennemses og behandles i et eksternt system med henblik på generering af afregning. Dagligt eller på nærmere specificeret tidspunkter Løsningen udstiller data til Anvendersystemer, jf. use case A3. Løsningen 1. Løsningen logger informationer om forbrug i forbindelse med alt ekstern anvendelse, som fx ved anmodning om udtræk fra Løsningen (se Behov.Alm.05). 2. Løsningen genererer et udtræk af forbrugsinformationer og gør udtrækket tilgængeligt for eksterne systemer (se Behov.Alm.06). Forbrugsudtræk kan inspiceres og indlæses i Anvendersystem. Følgende overordnede behov er tilknyttet use case B5. Behov.Alm.05. Forbrugsinformationer Løsningen skal logge forbrugsinformationer omkring anvendelse af udstillede data, der tillader afregning efter forbrug, herunder tidspunkt, Anvendersystem, type og volumen af data, der er tilgået og eventuelle tilmeldinger om ændringsadviseringer. Behov.Alm.06. Udtræk af forbrugsinformationer Løsningen kan indsamle information om forbrug af data fra Løsningen til Anvendersystemet og stille denne information til rådighed for Anvendersystemet som et udtræk. Løsningen understøtter, at Anvendersystemet selv henter de forbrugsinformationer, der er gjort tilgængelige via Løsningen. Forbrugsinformation skal være i gængse maskinlæsbare formater. 4.9 Use case B6: Administrer services Løsningen skal understøtte visning af en oversigt fx gennem en brugergrænseflade af de services, der på et givet tidspunkt er publiceret (udstillet) via Løsningen. Denne oversigt skal sikre, at nye services kan udstilles, redigeres eller fjernes fra samlingen af udstillede services. Løsningen kan desuden understøtte versionering, hvilket vil sige, at den samme service er udstillet i forskellige versioner. 27

Use case B6 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Administrer services At de services, der er udstillet på Løsningen, kan administreres. Dagligt eller på nærmere specificeret tidspunkter Der findes en administrationsgrænseflade, der tillader administration af services. Løsningen, Administrator 1. Administratoren kan administrere services, herunder oprette, vise, redigere og slette services (se Behov.Høj.28, Behov.Høj.29, Behov.Alm.07 og Behov.Alm.08). Administratoren har udført den ønskede inspektion eller administration af services i Løsningen. Følgende overordnede behov er tilknyttet use case B6. Behov.Høj.28. Administration af de services der udstilles på Løsningen Løsningen kan administrere de services, der udstilles på Løsningen, herunder tilføje nye, vise, redigere og slette services. Dette kan fx realiseres ved konfiguration af Løsningen. Behov.Høj.29. Publicering (udstilling) af services Løsningen kan publicere en service i et servicekatalog, og sikre at servicen herefter kan tilgås af Anvendersystemet. Dette kan fx realiseres ved konfiguration af Løsningen. Behov.Alm.07. Versionering af services Løsningen understøtter versionering af services. Det vil sige, at Løsningen tillader at services er tilgængelige i flere versioner samtidigt og kan tilgås af forskellige Anvendersystemer. Behov.Alm.08. Katalog over services Løsningen kan sammenstille et katalog over publicerede services, der kan gøres tilgængeligt for et Anvendersystem, forudsat at brugeren er Administrator. 4.10 Use case B7: Driftsovervågning Løsningen skal understøtte driftsovervågning af Løsningen, således at et driftsovervågningssystem løbende kan sikre, at Løsningen er operativ. Use case B7 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Driftsovervågning At det kan overvåges, at Løsningen fungerer efter hensigten og er operativ, samt at nedbrud af Løsningen kan opdages snarest muligt. Kontinuerligt. Løsningen, Driftsovervågning Driftsovervågningen er i stand til at forespørge Løsningen, om denne fungerer efter hensigten, idet Løsningen udstiller en grænseflade med dette formål (se Behov.Høj.30, Behov.Alm.09, og Behov.Alm.10). Driftsovervågningen er orienteret om, hvorvidt Løsningen 28

fungerer efter hensigten og er operativ. Følgende overordnede behov er tilknyttet use case B7. Behov.Høj.30. Driftsovervågning Løsningen understøtter basal driftsovervågning for at sikre tilgængelighed i Løsningen, fx i form af driftslogning. Behov.Alm.09. Snitflade til driftsovervågning Løsningen stiller en grænseflade til rådighed, der tillader et eksternt, automatiseret monitoreringssystem at forespørge på aktuel driftsstatus. Behov.Alm.10. Udtræk af driftslog Løsningen kan understøtte udtræk af den information, der logges i forbindelse med drift, således at en driftsrapport kan udfærdiges. 4.11 Use case B8: Administrer og afsend ændringsadviseringer Løsningen skal afsende ændringsadviseringer til Anvendersystemet på baggrund af de ændringsadviseringer, som Anvendersystemet er tilmeldt. Det skal derfor være muligt for Anvendersystemet at tilføje, fjerne eller redigere tilmeldinger til ændringsadviseringer. Tilmeldinger kan have tilknyttede parametre, som fx frekvens for adviseringer. Use case B8 Administrer og afsend ændringsadviseringer Formål Understøtte Anvendersystemets administration og af tilmeldinger om ændringsadviseringer, og afsende ændringsadviseringer på baggrund af Anvendersystemets tilmeldinger til ændringsadviseringer. Frekvens Dagligt eller på nærmere specificeret tidspunkter Startbetingelser Administration af tilmeldinger til ændringsadviseringer er muligt. Løsningen er i stand til at generere ændringsadviseringer i forbindelse med relevante ændringer i totaludtrækket, jf. use case A1 og A2. Aktører Overordnet forløb Slutbetingelser Løsningen, Anvendersystemet 1. Det er muligt at administrere tilmeldinger til ændringsadviseringer og angive parametre i forbindelse med tilmeldingen (se Behov.Høj.31, Behov.Høj.32, Behov.Høj.33, og Behov.Høj.34). 2. Baseret på disse tilmeldinger foretager Løsningen ændringsadviseringer i forbindelse med ændringer i Løsningens totaludtræk (se Behov.Høj.31, Behov.Høj.36, Behov.Høj.37, Behov.Høj.38, og Behov.Alm.11). Et Anvendersystem er tilmeldt ønskede ændringsadviseringer, og Løsningen adviserer på baggrund af de ønskede tilmeldinger ved ændringer i totaludtrækket. Følgende overordnede behov er tilknyttet use case B8. 29