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

2

4.6 Use case B3: Validering og sikring af datakvalitet........................................24

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.

4

Behovsprioritet Betegnelse Beskrivelse

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.

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

5

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.

6

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.

7

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.

8

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.

9

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 arkitekturprincipper2.

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 adaptere3 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-oio-arkitekturarbejdet/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.

10

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

11

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

12

Kunden kan efter behov hente parameterbestemte udtræk af CPR-data fra Løsningen under overholdelse af krav til sikkerhed, mv.

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 FTP4. 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 server5. 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 filtransmis-sion her: http://www.cpr.d k

13

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 gives en tekstuel beskrivelse af de arkitekturprincipper, som Løsningen skal bygge på. De konkrete krav til arkitektur fremgår af underafsnit 5.1.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: http://www.cpr.d k ;”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

14

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 OIO-godkendte 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.

15

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.

16

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. Non-funktionelle 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 Abonnerer på og udtrækker data fra

17

hos Kunden. 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 af Kunden udpeget database med CPR-data.

Udstiller CPR-data til Løsningen

Driftsovervågning Repræsenterer et it-system, der er i stand til at overvåge Løsningen.

Overvåger løbende Løsningen og sikrer, at den er operativ.

I tillæg til aktørerne benyttes nedenstående begreber om udtræk.

Udtrækstype Beskrivelse

Registerudtræk Initielt dumpudtræk fra CPR-registret til Løsningen, jf. use case A1.

Registerændringsudtræk Løbende udtræk af ændringer fra CPR-registret til Løsningen, jf. use case A2

Totaludtræk 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.

(Øvrige) udtræk 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 CPR-registret.

18

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 Løsningen, CPR-registret, Anvendersystemet

Overordnet forløb1. Løsningen henter et registerudtræk fra CPR-

registret (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).

Slutbetingelser Løsningen har kvitteret for gennemført registerudtræk, adviseringer er overført, og det ny totaludtræk er udstillet til Anvendersystemet.

Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A1.

19

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.

20

Behov.Høj.01. Hente registerudtræk fra CPR-registretLø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ækLø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ækLø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ækLø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ækLø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 CPR-registret, 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 CPR-registret.

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

21

Overordnet forløb1. 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).

Slutbetingelser 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.

22

Figur 8 Use case A2: Modelskitse for registerændringsudtræk fra CPR-registret til Løsningen.

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.

23

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ækLø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ækLø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.

Use case A3 Overfør udtræk

Formål Anvendersystemet kan konfigurere og hente et nærmere specificeret udtræk fra Løsningens totaludtræk.

Frekvens Dagligt eller på nærmere specificeret tidspunkt

Startbetingelser Løsningen lagrer et komplet, aggregeret totaludtræk fra CPR-registret, jf. use case A1 og A2.

Aktører Løsningen, Anvendersystemet

24

Overordnet forløb1. 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).

Slutbetingelser Det ønskede udtræk er overført til Anvendersystemet.

Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A3.

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.

25

Behov.Høj.13. Anmodning om overførsel af udtrækLøsningen kan modtage en anmodning om overførsel af et udtræk fra Anvendersystemet.

Behov.Høj.14. Overførsel af udtrækLø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ækLø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æksparametreI 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æksparametreLø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 Indlæsningsformater

Formål Løsningen er i stand til at indlæse alle data ved registerudtræk og registerændringsudtræk fra CPR-registret.

Frekvens Dagligt eller på nærmere specificeret tidspunkt

Startbetingelser Data fra CPR-registret er tilgængelige for Løsningen, jf. use case A1 og A2.

Aktører Løsningen

Overordnet forløb 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).

Slutbetingelser Data er indlæst i Løsningen.

Følgende overordnede behov er tilknyttet use case B1.

26

Behov.Høj.18. Indlæsning af registerudtrækLøsningen kan indlæse registerudtræk fra CPR-registeret, jf. specifikationen6.

Behov.Høj.19. Indlæsning af registerændringsudtrækLøsningen kan indlæse registerændringsudtræk fra CPR-registeret7.

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øb1. 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.

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.

27

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øsningenLø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 servicesLø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 dataLø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øsningenLø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 registerændringsudtræk sker korrekt, at modtagne data er formateret korrekt, og at indholdet er korrekt.

Use case B3 Validering og sikring af datakvalitet

Formål Sikre, at de data, der indlæses i Løsningen, er af tilstrækkelig kvalitet.

Frekvens I forbindelse med modtagelse af registerudtræk og registerændringsudtræk fra CPR-registret.

Startbetingelser At data fra CPR-registret er overført, jf. use case A1 og A2.

Aktører Løsningen

Overordnet forløb1. 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

28

dataspecifikationerne for CPR-data (se Behov.Høj.23, Behov.Høj.24 og Behov.Høj.25)..

Slutbetingelser 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ørselLø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 dataformatLø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 dataindholdLø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).

Behov.Høj.24. Validering af CPR-formatetLøsningen kan validere, at dataformat er som specificeret8 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 valideringsproblemerLø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 Udtræk af logningsinformation

Formål At logningsinformation fra Løsningen kan gennemses og behandles i et eksternt system.

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.

29

Frekvens Dagligt eller på nærmere specificeret tidspunkter

Startbetingelser Løsningen udstiller udtræk til Anvendersystemet, jf. use case A1, A2 og A3.

Aktører Løsningen

Overordnet forløb1. 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).

Slutbetingelser 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 logningLø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 logningsinformationerLø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.

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 Udtræk af forbrugsinformation

Formål At forbrugsinformation fra Løsningen kan gennemses og behandles i et eksternt system med henblik på generering af afregning.

Frekvens Dagligt eller på nærmere specificeret tidspunkter

30

Startbetingelser Løsningen udstiller data til Anvendersystemer, jf. use case A3.

Aktører Løsningen

Overordnet forløb1. 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).

Slutbetingelser Forbrugsudtræk kan inspiceres og indlæses i Anvendersystem.

Følgende overordnede behov er tilknyttet use case B5.

Behov.Alm.05. ForbrugsinformationerLø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 forbrugsinformationerLø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.

Use case B6 Administrer services

Formål At de services, der er udstillet på Løsningen, kan administreres.

Frekvens Dagligt eller på nærmere specificeret tidspunkter

31

Startbetingelser Der findes en administrationsgrænseflade, der tillader administration af services.

Aktører Løsningen, Administrator

Overordnet forløb 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).

Slutbetingelser 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øsningenLø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 servicesLø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 servicesLø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 servicesLø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 Driftsovervågning

Formål At det kan overvåges, at Løsningen fungerer efter hensigten og er operativ, samt at nedbrud af Løsningen kan opdages snarest muligt.

Frekvens Kontinuerligt.

Startbetingelser

Aktører Løsningen, Driftsovervågning

32

Overordnet forløb 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).

Slutbetingelser Driftsovervågningen er orienteret om, hvorvidt Løsningen fungerer efter hensigten og er operativ.

Følgende overordnede behov er tilknyttet use case B7.

Behov.Høj.30. DriftsovervågningLø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ågningLø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 driftslogLø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 Løsningen, Anvendersystemet

33

Overordnet forløb1. 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).

Slutbetingelser 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.

Behov.Høj.31. Administration af tilmeldinger om ændringsadviseringLøsningen understøtter administration af tilmeldinger om ændringsadvisering, herunder at oprette, vise, ændre og slette tilmeldinger. Tilmeldingerne skal kunne specificeres på flere niveauer, herunder også feltniveau, således at Anvendersystemet kan abonnere på ændringer i enkeltfelter i CPR-data. Dette kan fx realiseres ved konfiguration af Løsningen eller ved redigering af konfigurationsfiler.

Behov.Høj.32. Frekvens af ændringsadviseringLøsningen understøtter angivelse af en frekvens for ændringsadviseringer. Det vil sige, hvor ofte en advis skal sendes til et Anvendersystem, og at frekvensen for adviseringer kan oprettes, vises, ændres og slettes. Når Løsningen adviserer Anvendersystemet, inkluderes alle ændringer, der er sket i frekvensperioden. Det vil sige, hvis fx frekvensen er månedlig, så inkluderer ændringsadviseringen alle ændringer, der er sket den seneste måned.

Behov.Høj.33. Metode for ændringsadviseringerLøsningen understøtter konfiguration af metode for ændringsadviseringer, fx at Anvendersystemet selv er ansvarlig for at kontrollere for og hente ændringsadviseringer, og at Løsningen er ansvarlig for at sende adviseringer til Anvendersystemet.

Behov.Høj.34. Overførselsprotokol for ændringsadviseringerLøsningen understøtter konfiguration af den protokol, der anvendes til at overføre ændringsadviseringer til Anvendersystemet.

Behov.Høj.35. Advisering Løsningen genererer advisering, fx som adviseringsdokument indeholdende de ændringer, der er sket i forbindelse med en ny udgave af det samlet CPR-datasæt på Løsningen.

Behov.Høj.36. Overførsel af adviseringsdokumentLøsningen understøtter, at Anvendersystemet selv henter adviseringsdokumenter, der er gjort tilgængelige via Løsningen.

Behov.Høj.37. Automatisk overførsel af adviseringsdokumentLøsningen understøtter, at et genereret adviseringsdokument automatisk overføres til Anvendersystemet.

34

Behov.Alm.11. Advisering via webserviceLøsningen understøtter, at et adviseringsdokument overføres via en webservice, der udstilles af Anvendersystemet.

Behov.Høj.38. Kvittering for ændringsadviseringerLøsningen understøtter kvittering for ændringsadviseringer, når 1) et Anvendersystem henter adviseringer, og 2) Løsningen overfører adviseringer. Såfremt overførslen er sket uden fejl, skal Løsningen automatisk markere ændringsadviseringen som gennemført.

4.12 Use case B9: Persistering (lagring) af data

Løsningen skal understøtte persistering af data på et pålideligt medie.

Use case B9 Persistering af data

Formål At Løsningen kan tilbyde opdaterede data, også hvis Løsningen genstartes.

Frekvens Ved indlæsning af registerudtræk og registerændringsudtræk, jf. use case B1.

Startbetingelser

Aktører Løsningen

Overordnet forløb1. Når et registerudtræk eller et

registerændringsudtræk hentes fra CPR-registret, kan det lagres i Løsningen, fx som en fil (se Behov.Høj.39).

2. Når et registerudtræk eller et registerændringsudtræk er valideret og indlæst, lagres data i normaliseret form på et pålideligt medie, som fx en relationel database (se Behov.Høj.40, Behov.Høj.41, og Behov.Høj.42).

Slutbetingelser Data fra registerudtrækket eller registerændringsudtrækket er lagret permanent, og det kan tilbydes selvom Løsningen skal genstartes.

Følgende overordnede behov er tilknyttet use case B9.

Behov.Høj.39. Persistering af registerudtræk og registerændringsudtrækLøsningen kan persistere de registerudtræk og registerændringsudtræk, der modtages fra CPR-registret, jf. use case A1 og A2. Løsningen bør understøtte lagring på filniveau.

Behov.Høj.40. Persistering af totaldata Løsningen kan persistere totaludtrækket, jf. use case B1. Løsningen bør understøtte lagring på filniveau.

35

Behov.Høj.41. Persistering af metadataLøsningen kan persistere metadata, således at disse fx kan anvendes i Løsningen, og udbydes til Anvendersystemet, jf. håndtering af metadata i use case B2.

Behov.Høj.42. Persistering af konfigurationLøsningen kan persistere konfigurerbare elementer af services, fx konfigurerede udtræksparametre eller konfiguration af metode for ændringsanvisninger.

36

5. Non-funktionelle krav

De non-funktionelle krav skal sikre kvaliteten i Løsningens arkitektur og design, hvilket adskiller sig fra de funktionelle krav, der sikrer Løsningens funktionsunderstøttelse (beskrevet i afsnit 4). De non-funktionelle krav til selve Løsningen er opdelt i følgende områder:

Arkitektur, jf. afsnit 5.1 Sikkerhed, jf. afsnit

Vedligeholdelse og videreudvikling, jf. afsnit 5.3

Portabilitet, jf. afsnit 5.4

Effektivitet og skalering, jf. afsnit 5.5

Pålidelighed og tilgængelighed, jf. afsnit 5.6

De non-funktionelle krav er defineret ved følgende typer af krav:

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.

Prioriteringen af krav tager udgangspunkt i, at krav, der er identificeret af Kunden som nødvendige for Løsningen, har prioritet af Mindstekrav. Øvrige krav forventes at være væsentlige, men ikke nødvendige, for Løsningen.

5.1 Arkitekturprincipper

For at sikre, at Løsningen udvikles efter hensigterne om en fremtidig arkitektur hos Kunden, forventes det, at Løsningen designes således, at den opfylder en række krav til arkitektur, som Kunden forudser vil skulle anvendes for Kundens fremtidige infrastruktur.

Kunden ønsker en arkitektur for Løsningen, der er baseret på serviceorientering. Funktionalitet til brugere af Løsningen skal udstilles som services. IT og Telestyrelsen har i forbindelse med IT arkitekturarbejde udgivet en pjece om serviceorienteret

37

arkitektur9, der skal danne grundlag for arkitekturen i Løsningen, herunder serviceorienteringen, i Løsningen.

Kunden ønsker en fleksibel arkitektur for Løsningen, der tillader, at Løsningen omkostningseffektivt kan udvides med funktionalitet af forskelligartet natur. For eksempel skal det være muligt at udvide Løsningen, så der skabes adgang til flere forskellige andre registre end CPR-registret og udvide Løsningen med forretningsprocesser og monitorering af disse.

Kunden ønsker en fleksibel og skalerbar arkitektur, der tillader, at Løsningens leverede effekt og ydelse kan øges ved tilførsel af hardwareressourcer.

Kunden ønsker, at Løsningen i videst muligt omfang anvender programmel baseret på open source-principper, der giver Kunden adgang til og ret til at foretage ændringer i kildekoden.

Krav.Alm.01. Arkitekturkrav Løsningen skal anvende en serviceorienteret arkitektur, der er fleksibel og skalerbar.

Krav.Alm.02. Offentlige standarderLøsningen skal anvende relevante fællesoffentlige standarder. Særligt relevant er, at CPR-data i videst muligt omfang stilles til rådighed for Anvendersystemet som OIOXML.

Krav.Alm.03. Anvendelse af open source Løsningen skal anvende produkter, der er baseret på open source licens. Derved forstås, at kildekoden til Løsningen gøres frit tilgængelig som nærmere defineret i kontrakten.

Krav.Alm.04. StandardkomponenterI det omfang der forefindes egnede, robuste og afprøvede standardkomponenter, skal Løsningen anvende disse frem for kundespecifikt programmel.

5.2 Sikkerhed

Løsningen skal kunne behandle og lagre personoplysninger. Det er derfor afgørende, at Løsningens arkitektur gør det muligt for Kunden at overholde relevant lovgivning, herunder Persondataloven.

Der skelnes mellem adgang til selve Løsningen og til CPR. Adgang til Løsningen skal kontrolleres, således at administrative opgaver i forbindelse med Løsningen kan varetages af autoriserede personer (Administratorer). Adgang til CPR-data, der udstilles på Løsningen, skal ligeledes kunne kontrolleres, således at Kunden kan opfylde Persondataloven og Sikkerhedsbekendtgørelsen. Konkret skal adgang kontrolleres, så eneste eksterne systemer, der har adgang til CPR-data i Løsningen, er Anvendersystemet stillet til rådighed af Kunden. Anvendersystemets overholdelse af Persondataloven og Sikkerhedsbekendtgørelsen er Kundens ansvar.

Krav.Min.01. Sikkerhedsarkitektur

9 http://www.itst.dk/it-arkitektur-og-standarder/it-arkitektur/serviceorienteret-arkitektur-serviceorienteret-infrastruktur/serviceorienteret-arkitektur/soa/Pjece_Serviceorienteret_arkitektur.pdf

38

Løsningens arkitektur skal sikre autentificering af brugere, at brugere har den nødvendige autorisation for at tilgå data, og at der er sporbarhed og logning i forbindelse med adgang til data.

Krav.Alm.05. Overholdelse af DS484Leverandørens sikkerhedspolitik skal være udformet, så de "tekniske dele" af DS484 (inkl. den del der vedrører behandling af personfølsomme oplysninger), er opfyldt.

Krav.Min.02. Overholdelse af persondatalovenLøsningen skal understøtte, at Kunden kan behandle personoplysninger i henhold til persondataloven, herunder Sikkerhedsbekendtgørelsen, Datatilsynets praksis vedrørende behandling af person oplysninger og i overensstemmelse med god databehandlingsskik.

Krav.Min.03. Sletning af dataLøsningens arkitektur skal sikre, at det er muligt at slette alle data i Løsningen.

Krav.Alm.06. Rollebaseret adgangskontrol til LøsningenLøsningen skal anvende rollebaseret adgangskontrol til selve Løsningen, så det er muligt at styre adgang til data via roller, i stedet for på den enkelte bruger.

Krav.Alm.07. Sporbarhed i brugeraktiviteter og sikkerhedsrelaterede hændelser

Løsningen skal implementere sporbarhed i brugeraktiviteter og sikkerhedsrelaterede hændelser. Dette kan fx realiseres via logning af brugeraktiviteter på forretningsniveau der kan spores til den enkelte bruger og dennes placering (IP adresse), og via logning af alle sikkerhedsrelaterede hændelser såsom når adgang gives eller nægtes, og begrundelse herfor.

Krav.Min.04. Adgangskontrol i forbindelse med personhenførbare dataLøsningen skal sikre, at al adgang til CPR-data er kontrolleret, før adgangen gives. Dette kan fx realiseres ved at sikre i de udstillede services eller via Løsningens infrastruktur, at brugeren er autentificeret og autoriseret, før bagvedliggende systemer eller registre tilgås.

Krav.Alm.08. Logning af adgang til alle dataLøsningen skal sikre at der altid logges i forbindelse med al adgang til data, der udstilles via Løsningen. Dette kan fx realiseres hvis Løsningen kan konfigureres til at sikre logning af adgang for alle udstillede services.

Krav.Alm.09. Adgangskontrol integreret til brugerregisterLøsningen skal kunne integrere kontrol af adgang til Løsningen til et brugerregister, der autentificerer interne brugere.

5.3 Vedligeholdelse og videreudvikling

Løsningen skal designes således, at den uden videre kan vedligeholdes.

Krav.Min.05. Løsningen kan vedligeholdes og videreudviklesLøsningens design og struktur skal være således, at den kan videreudvikles og vedligeholdes løbende. Løsningens design og struktur skal tillade rettelser og tilpasninger, uden at hele Løsningen skal genimplementeres.

5.4 Portabilitet

Løsningen skal designes således, at den uden større besvær kan porteres til forskellige driftsplatforme. Dermed er Kunden ikke anvist til en type driftsplatform.

39

Krav.Alm.10. Portabilitet omkring driftsplatformeLøsningen skal kunne installeres på og porteres til forskellige driftsplatforme, såfremt platformene opfylder Løsningens krav hertil. Dette kan fx være forskellige typer af hardware, såfremt denne hardware er i stand til at afvikle den krævede basisplatform (som fx operativsystem).

Krav.Alm.11. Portabilitet omkring brug af standardkomponenterLøsningen skal kunne porteres mellem forskellige implementeringer af standardkomponenter, såfremt disse komponenter fuldt implementerer den pågældende standard. Dette kan fx være portabilitet mellem relationelle databaser, der opfylder en tilstrækkelig grad af SQL-standarder.

5.5 Effektivitet og skalering

Løsningen under Kontrakten skal tilgås af et enkelt Anvendersystem hos Kunden (Anvendersystemet). Løsningen skal imidlertid designes således, at den vil kunne skaleres til en række anvendersystemer og samtidig overholde krav om effektivitet og svartider. Med effektivitet menes, at Løsningen skal anvende de ressourcer, der stilles til rådighed – som fx CPU, harddisk, netværk, databaser – så disses ydelse ikke reduceres i urimeligt omfang, når de indgår som en del af Løsningen. Dette kan realiseres ved at udnytte ressourcerne efter best practice; fx kan dedikerede transportprotokoller, anvendes til at transportere data med. Endvidere kan data med fordel indlæses i databaser ved hjælp af særlige grænseflader, der er beregnet til indlæsning af store datamængder.

Krav.Min.06. Effektiv håndtering af store datamængderLøsningen skal kunne håndtere datamængder på mindst 100 MB effektivt i forbindelse med validering, indlæsning og normalisering, samt overførsel til Anvendersystemer.

Krav.Alm.12. SkaleringLøsningen skal kunne skaleres gennem tilføjelse af yderligere ressourcer til Løsningens drift, således at Løsningen kan levere den samme performance til flere anvendersystemer eller ved større datamængder.

5.6 Pålidelighed og tilgængelighed

Løsningen skal designes således, at den uden videre kan anvendes døgnet rundt.

Såfremt Løsningen holder op med at fungere efter specifikationerne, skal dette kunne opdages hurtigt, og det skal være muligt hurtigt at reetablere Løsningen. Leverandøren er ansvarlig for at levere Løsningen i drift indtil Driftsprøvens afslutning, samt levere den relevante system- og driftsdokumentation. Se afsnit 6.1 for krav til den leverede dokumentation og afsnit 6.4 for servicemål for Løsningen.

Krav.Alm.13. RobusthedLøsningen skal være robust, hvilket vil sige, at Løsningen fortsætter med at fungere efter specifikationerne på trods af ikke-fatale fejl.

Krav.Alm.14. Reetablering af LøsningenDet skal være muligt, ved at følge systemdokumentationen, at reetablere Løsningen inden for 2 døgn, dog undtaget genetablering af de data, der er lagret i Løsningen. Data skal være genetableret inden for et yderligere døgn.

40

Krav.Alm.15. OvervågningLøsningen understøtter overvågning af Løsningen fra et driftsovervågningssystem, således at driftscenteret løbende kan verificere, at Løsningen fungerer efter specifikationerne og er tilgængelig.

Krav.Alm.16. DriftslogningLøsningen foretager driftslogning af alle afviklede programmer og komponenter, således at det er muligt at overvåge at al afvikling foregår efter specifikationerne, og at det giver mulighed for reaktion såfremt fejl opstår.

Krav.Alm.17. FejlhåndteringLøsningen håndterer ikke-fatale fejl ved at sikre at informationer vedrørende fejlen er passende logget, og at der korrigeres korrekt for eventuelle delvist udførte operationer, således at Løsningen funktionelt fremstår som inden den fejlende operation blev forsøgt udført.

Krav.Alm.18. Automatisk backupLøsningen kan konfigurere automatisk backup af konfigurationsdata og data, således at hurtig reetablering af Løsningen inklusive dens data er muligt.

41

6. Relaterede ydelser

Nærværende afsnit indeholder Kundens krav til:

Dokumentation, jf. afsnit 6.1 Etablering og drift af et udviklings- og testmiljø, jf. afsnit 6.2

Overdragelse, jf. afsnit 6.3

Servicemål i perioden indtil Driftsprøvens afslutning, jf. afsnit 6.4

6.1 Dokumentation

I nærværende afsnit angiver Kunden sine krav til dokumentation. Nedenstående tabel viser de tre typer dokumentation, som skal leveres under Kontrakten

Type Beskrivelse

Systemdokumentation Betegner dokumentation, der beskriver Løsningens konstruktion og grænseflader, herunder hvordan Løsningen vedligeholdes og videreudvikles.

Driftsdokumentation Betegner dokumentation, der er rettet imod driften af Løsningen, herunder de servere, platforme og netværkskomponenter, værktøjer og systemer, der anvendes, og de procedurer, der skal følges.

Brugerdokumentation Betegner dokumentation, der er rettet imod anvendelsen af Løsningen. Herunder regnes dokumentation, der tillader adgang til data udstillet af Løsningen, og dokumentation, der tillader tredjepart at udvikle nye komponenter på den etablerede platform.

6.1.1 Generelle krav til dokumentation

Nedenfor præsenteres de generelle krav til dokumentationen. Disse gælder for al den dokumentation, der udfærdiges i forbindelse med Løsningen.

Krav.Alm.19. Dokumentationen skal kunne redigeresAl dokumentation skal afleveres i elektronisk og redigerbar form.

Krav.Alm.20. Dokumentation skal være aktuelAl dokumentation skal til enhver tid afspejle den løsning, der leveres til Kunden, med tydelig versionsangivelse.

42

6.1.2 Krav til systemdokumentation

Nedenfor præsenteres de specifikke krav til systemdokumentationen, der udgøres af arkitekturdokumentation, designdokumentation, grænsefladedokumentation, databasedokumentation samt udviklings- og vedligeholdelsesdokumentation.

Krav.Min.07. Krav til systemdokumentationLeverandøren skal levere systemdokumentation, der omfatter alle relevante dele af Løsningen.

Krav.Min.08. ArkitekturdokumentationLeverandøren skal levere løsnings- og arkitekturdokumentation, der beskriver Løsningens komponenter og disses interaktioner.

Krav.Alm.21. DesigndokumentationLeverandøren skal levere designdokumentation, der beskriver design og relevante dele af implementeringen af kundespecifikt programmel.

Krav.Alm.22. GrænsefladedokumentationLeverandøren skal levere dokumentation af udstillede grænseflader, der beskriver eventuelle protokoller og dataformater, der skal anvendes.

Krav.Alm.23. DatabasedokumentationLeverandøren skal levere dokumentation af anvendelsen af databaser, herunder skemaer, tabeller, stored procedures og views.

Krav.Min.09. Udviklings- og vedligeholdelsesdokumentationLeverandøren skal levere udviklings- og vedligeholdelsesdokumentation, der sikrer mulighed for overdragelse til tredjepart af udvikling og vedligehold.

6.1.3 Krav til driftsdokumentation

Nedenfor præsenteres de specifikke krav til driftsdokumentation, der udgøres af driftsarkitekturdokumentation, installationsdokumentation, dokumentation af opsætning, administrationsdokumentation, og etablerings- og vedligeholdelsesdokumentation. Krav til etablering og drift er specificeret i afsnit 6.2.

Krav.Min.10. DriftsarkitekturdokumentationLeverandøren skal levere dokumentation af driftsarkitekturen af de systemer, der sættes i drift (udviklingsmiljø og testmiljø), herunder eventuelle forudsætninger om driftsmiljøet, fx netværk og servere, således at Kunden har mulighed for at skifte driftsplatform.

Krav.Min.11. InstallationsdokumentationLeverandøren skal levere dokumentation af installation og konfiguration, så Løsningen kan installeres og konfigureres korrekt i udviklingsmiljø og testmiljø.

Krav.Alm.24. KonfigurationsdokumentationLeverandøren skal levere dokumentation af konfiguration, herunder af eventuelle batch jobs til databaser, skedulerede jobs, og konfiguration af brugerprofiler til udviklingsmiljø og testmiljø.

Krav.Alm.25. AdministrationsdokumentationLeverandøren skal levere tilstrækkelig dokumentation til, at Løsningen kan administreres i drift i udviklingsmiljø og testmiljø, herunder sikkerhedsadministration (styring af adgangsrettigheder), opstart og nedlukning af Løsningen, og andre systemspecifikke procedurer.

43

Krav.Alm.26. VedligeholdelsesdokumentationLeverandøren skal levere dokumentation af vedligehold af Løsningen, herunder procedurer for backup og restore.

Krav.Alm.27. OvervågningsdokumentationLeverandøren skal levere dokumentation af, hvordan Løsningen understøtter overvågning, herunder hvordan Løsningen overvåges, og hvilke drifts og logfiler, der skal overvåges.

6.1.4 Krav til brugerdokumentation

Nedenfor præsenteres de specifikke krav til brugerdokumentation. Herunder regnes dokumentation, der tillader adgang til data udstillet af Løsningen, og dokumentation, der tillader tredjepart at udvikle nye komponenter på den etablerede platform. Krav til overdragelse fremgår af afsnit 6.3.

Krav.Alm.28. Krav til brugerdokumentationLeverandøren skal levere brugerdokumentation, der på nem og overskuelig vis tillader Kunden at anvende Løsningen.

Krav.Alm.29. Dokumentation til udviklingLeverandøren skal levere dokumentation, der muliggør udvikling af nye komponenter på Løsningen.

6.2 Etablering og drift af test- og udviklingsmiljø

I dette afsnit præsenteres Kundens krav til etablering og drift af de it-miljøer, der skal etableres og driftes af Leverandøren indtil Driftsprøven er gennemført og godkendt. Indledningsvist gives en tekstuel præsentation af et udviklings- og testmiljø. Efterfølgende præsenteres de specifikke krav.

Formålet med Løsningen er at levere CPR-data til Kunden. Løsningen skal hente CPR-data via registerudtræk og registerændringsudtræk fra CPR-registeret. Løsningen udstiller en simpel grænseflade imod Kunden, hvorfra Anvendersystemet kan hente udtræk i forhold til seneste totaludtræk på nærmere bestemte intervaller. Grænsefladen overholder den datamodel, inklusiv databeskrivelse, som leverandøren har afleveret til Kunden 5 uger inden funktionel overtagelsesprøve.

Følgende figur illustrerer de it-systemer, der er relevante for etablering af Løsningen.

44

Figur 10 Oversigt over it-systemer i forbindelse med Løsningen.

Anvendersystemet og CPR-registret er etablerede og skal dermed ikke tilvejebringes i forbindelse med Løsningen. Øvrige systemer skal etableres af Leverandøren. Det vil sige et udviklingsmiljø og et testmiljø etableres, sammen med en sikret forbindelse til Internettet og lokalnet.

Testmiljøet fungerer som pilotmiljø. Al afprøvning foregår som udgangspunkt i testmiljøet.

6.2.1 Forbindelse til CPR

Ifølge krav og betingelser fra CPR-registeret, skal forbindelsen til CPR-registret etableres som en sikker FTP-forbindelse. Løsningen skal agere som sikker FTP-klient10 imod CPR-registerets FTP-server. De brugernavne, passwords og andre adgangsbetingelser, der skal anvendes i forbindelse med adgang til CPR-registeret, leveres af Kunden til Leverandøren.

Krav.Alm.30. Adgang til CPR-registeretLøsningen skal som sikker FTP-klient kunne tilgå CPR-registerets FTP server, for at hente registerudtræk og registerændringsudtræk, og i denne forbindelse overhold CPR-registerets krav til adgang, fra både udviklingsmiljøet og testmiljøet.

10 Ved sikker FTP forstås her en kombination af FTP protokollen og en TLS forbindelse, der således overfører data på en krypteret, gensidigt autentificeret forbindelse. Dette er beskrevet i RFC 4217.

45

6.2.2 Forbindelse til Kunden

Løsningen forventes at udstille CPR-data til Kunden på følgende vilkår.

Krav.Alm.31. Forbindelse til KundenLøsningen skal fra både udviklingsmiljø og testmiljø udstille CPR-data til Kunden på en HTTPS–baseret webservice og en sikker FTP-server.

Krav.Min.12. DataudtrækDet skal være muligt for Kunden via Anvendersystemet at hente eller anmode om et udtræk fra Løsningen indeholdende såvel CPR-data, metadata eller logningsinformation.

Krav.Alm.32. Advisering om ændringerLøsningen skal foretage adviseringer om ændringer ved at anvende HTTPS-webservice eller sikker FTP-server. I sidstnævnte tilfælde agerer Løsningen klient og Kundens Anvendersystem server i et klient-server-forhold.

6.2.3 Etablering af Løsningen

Kunden stiller i forbindelse med etablering af Løsningen alene Anvendersystemet til rådighed, hvorfor Leverandøren forventes at levere de øvrige it-miljøer. Leverandøren forventes at etablere et testmiljø og udviklingsmiljø.

Krav.Min.13. Etablering af udviklingsmiljøLeverandøren skal etablere et udviklingsmiljø hvor Løsningen kan installeres og konfigureres til udviklingsbrug

Krav.Min.14. Etablering af testmiljø Leverandøren skal etablere et testmiljø, hvor Løsningen kan installeres og konfigureres til afvikling af test og prøver

Krav.Min.15. Adgang til test- og udviklingsmiljøLeverandøren skal etablere test- og udviklingsmiljøet med en sikker og kontrolleret adgang til og fra Internettet, via en konfigureret firewall, herunder etablering af adgang via fast IP-adresse til Løsningen via protokollerne HTTPS og sikker FTP.

Krav.Alm.33. Klient-PCLeverandøren skal enten stille en PC lig en standard kunde-PC til rådighed for Kunden eller bringe en standard kunde-PC til at tilgå udviklings- og testmiljøet via et lokalt netværk og/eller Internettet. Ved en standard-PC forstås en 2,2GHz Intel Core 2 Duo E450 med 2 GB Ram og med Windows XP, SP2 (eller nyere), MS Internet Explorer 8.x, Antivirus mv.

Der forventes ikke dedikeret hardware til serverne i it-miljøet, forudsat at de krævede servicemål og den krævede sikkerhed kan opnås. Virtualisering kan derfor indgå som væsentlig del af Løsningens etablering.

6.2.4 Krav til etablering og drift af Løsningen

Følgende krav stilles til leverancen fra Leverandøren.

Krav.Alm.34. Virtualiseret platformLøsningen skal kunne afvikles på en virtualiseret platform. Såfremt Løsningens effektivitet kan forbedres væsentligt ved at stille særlige krav til virtualiseringen eller ved at undlade at anvende virtualisering for hele eller dele af Løsningen, skal dette eksplicit angives af Leverandøren.

46

Krav.Min.16. Drift af LøsningenLeverandøren skal levere drift af Løsningen på udviklingsmiljøet og testmiljøet indtil gennemført og godkendt Driftsprøve.

Krav.Alm.35. Backup og restoreLeverandøren skal levere backup af Løsningen, og af konfigurationsdata og data, der er indlæst i løsningen. Leverandøren skal kunne restore (gendanne) Løsningen, og Løsningens konfigurationsdata og data.

6.3 Overdragelse

Det er væsentligt, at vedligehold og videreudvikling af Løsningen kan overdrages til tredjepart. Det skal ligeledes være muligt for tredjepart at udvikle komponenter, der kan udstilles og afvikles på Løsningen. Dette skal primært sikres ved at overdrage kildekoden og eventuelt konfigurationsmateriale af Standardprogrammel til Kunden og gennem relevant dokumentation, jf. underafsnit 6.1.

Krav.Min.17. Overdragelse til tredjepartDet skal være muligt for Kunden at overdrage drift, vedligehold og videreudvikling af Løsningen til tredjepart efter levering af Løsningen. Som minimum skal kildekode til Kundespecifikt programmel og al relevant konfigurationsmateriale af komponenter leveres til Kunden i en stand, der gør Kunden i stand til at få tredjepart til at drifte, vedligeholde og videreudvikle Løsningen.

6.4 Servicemål til Driftsprøve

I nærværende afsnit har Kunden angivet sine krav i forbindelse med Løsningens servicemål. Leverandøren bedes bemærke, at servicemål alene vedrør perioden mellem funktionel overtagelsesprøve og driftsprøvens afslutning.

6.4.1 Rammer for Løsningens drift og service

Kunden skelner mellem tre tidsvinduer. De tre tidsvinduer fremgår af følgende tabel.

Type Tidsinterval Beskrivelse

Almindeligt adgangsvindue

Mandag til fredag fra 08:00 til 18:00

Almindelig driftsperiode, hvor Løsningen er tilgængeligt for Kundens Anvendersystem.

Batchvindue Mandag til søndag fra 22:00 til 04:00

Driftsperiode, hvor Løsningen kan opdateres med registerudtræk eller registerændringsudtræk fra CPR-registret.

Servicevindue Mandag til fredag fra 18:00 til 22:00 og fra 04:00 til 08:00, samt lørdag og søndag

Det tidsrum, hvor Leverandøren må påvirke miljøet, herunder medføre at elementer heraf er midlertidigt

47

utilgængelige.

Tabel 1 Definition af tidsvinduer

Krav.Alm.36. Almindelig KundeadgangLøsningen skal være tilgængelig for Anvendersystemet i 98 % af tiden i Almindeligt adgangsvindue, jf. Tabel 1 Definition af tidsvinduer.

Krav.Alm.37. BatchkørselLøsningen skal være tilgængelig for registerudtræk og registerændringsudtræk fra CPR-registret i 95 % af tiden i Batchvinduet, jf. Tabel 1 Definition af tidsvinduer. Registerudtræk og registerændringsudtræk fra CPR-registret skal være gennemført i Batchvinduet.

Krav.Alm.38. ServicevinduetLeverandøren kan frit lukke for adgang til Løsningen for at opdatere Løsningen i servicevinduet, jf. Tabel 1 Definition af tidsvinduer. Leverandøren kan ikke lukke for adgangen eller opdatere Løsningen uden for Servicevinduet med mindre dette konkret aftales med Kunden.

6.4.2 Krav til svartider

Løsningen forventes at skulle modtage et enkelt registerudtræk og op til 30 registerændringsudtræk fra CPR-registeret. Dertil kommer, at Løsningen skal overføre forskellige typer udtræk til Anvendersystemet.

I forbindelse med Driftsprøven forventes det, at et udsnit af CPR-registrets personposter vil skulle indgå. Omfanget af personposter i forbindelse med Driftsprøven vil være maksimum 25.000.

Der er følgende krav til svartider.

Krav.Alm.39. Svartid for indlæsning af registerudtræk fra CPR-registretLøsningen skal være i stand til at modtage, validere og kvittere for et komplet registerudtræk fra CPR-registret, samt etablere et totaludtræk inden for 5 minutter, jf. use case A1. Dette måles som tidsrummet fra selve overførslens afslutning og til totaludtrækket er tilgængeligt for Anvendersystemet. Forsinkelsen på eventuelle netværk medregnes ikke.

Krav.Alm.40. Svartid for indlæsning og beregning af ændringer/nyt totaludtræk

Løsningen skal være i stand til at indlæse et registerændringsudtræk fra CPR-registret og derefter udlede et nyt totaludtræk baseret på eksisterende totaludtræk og modtagne ændringer indenfor 10 minutter, jf. use case A2. Dette måles som tidsrummet fra selve overførslens afslutning og til totaludtrækket er tilgængeligt for Anvendersystemet.

Krav.Alm.41. Svartid for advisering af Anvendersystemet om ændringerEfter indlæsning af et registerudtræk eller et registerændringsudtræk fra CPR, skal Løsningen være i stand til at advisere Anvendersystemet om ændringer inden for 5 minutter, jf. use case A1 og A2. Dette måles som tidsrummet mellem sluttidspunktet for indlæsning af udtrækket eller ændringsudtrækket og starttidspunktet, hvor adviseringer sendes til Anvendersystemer. Forsinkelsen på eventuelle netværk medregnes ikke.

Krav.Alm.42. Svartid for overførsel af udtræk til KundenUnder overførsel af et udtræk til Anvendersystemet skal Løsningen være i stand til at overføre data inden for 1 minut, jf. use case A3. Dette måles som tidsrummet mellem starttidspunkt for at modtage anmodning om overførsel

48

og sluttidspunkt for overførslen. Forsinkelsen på eventuelle netværk medregnes ikke.

Krav.Alm.43. Reetableringstid for LøsningenReetablering af Løsningen (komplet installation eksklusiv installation af hardware og operativsystem) skal kunne foretages indenfor 2 døgn af en af Kunden udpeget kyndig person, der har erfaringer med installation af it-systemer og med konfiguration af det standardprogrammel, der indgår i Løsningen.

49