Embed Size (px)
Citation preview
4. februar 2011
BILAG 2
KRAVSPECIFIKATION
KOMBIT A/S Halfdansgade 8 2300 København S www.kombit.dk
2
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
3
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
4
1. Vejledning til Leverandøren
Dette bilag udgør Kundens kravspecifikation til Løsningen og relaterede ydelser, herun-
der 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 un-
derbilag 2B, Behovs- og kravsopfyldelse, den samlede beskrivelse af Løsningen og rela-
terede 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 un-
derbilag 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 priori-
tet 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.
5
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 opfyldel-
se omfatter. Hvis ikke Leverandøren indsætter en kommentar vurderes behovet som ”Ik-
ke 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 til-
buddet ikke er konditionsmæssigt.
Krav Krav.Alm Leverandøren skal i udgangspunktet opfylde det-
te krav og leverandørens opfyldelse af kravet ind-
går i vægtning af Leverandørens tilbud. Manglen-
de eller delvis opfyldelse vil ikke betyde, at tilbud-
det 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, angi-
ves ”Delvist opfyldt”. Angives ”Delvist opfyldt”, vurderes dette som et forbehold og Leve-
randøren skal i kommentarfeltet specificere, hvad forbeholdet for kravets opfyldelse om-
fatter. Hvis ikke Leverandøren indsætter en kommentar vurderes kravet som ”Ikke op-
fyldt”.
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 krav-
sopfyldelse
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 fin-
des 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 kravspe-
cificeret 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 Leve-
randø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 ud-
vikling 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 øn-
sker 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 un-
derstø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ælleskom-
ponenter.
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 anven-
der 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 kun-
ne udstilles (forudsat, at forretningslogik og teknologi er kompatibel med infrastrukturen).
Denne tværkommunale anvendelse forudsætter portalsupport, brugerstyring, mv. af in-
frastrukturen.
8
2.3 Løsningsarkitektur for fremtidig infrastruktur
For at imødekomme de skitserede forretningsbehov skal den fremtidige infrastruktur mu-
liggøre:
Aggregering og integration af data fra forskellige kildesystemer. Forskellige an-
vendere kan herefter tilgå disse data.
Udstilling af fælleskomponenter, fælles brugergrænseflader og generelt under-
støttelse af it-projekter hos Kunden.
Håndtering af sikkerhed. Eksempelvis må det i forbindelse med selvbetjenings-
lø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 un-
derstø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 an-
vendersystemer (fx en selvbetjeningsløsning i en kommune). Infrastrukturen udbyder si-
ne 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 stan-
dardkomponenter og Open Source og i øvrigt underlagt OIO-hvidbogens arkitekturprin-
cipper2.
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, ser-
vice-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 til-
gang 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 umid-
delbare forskelle i de underliggende databaser skjules for anvenderen af adapteren.
10
Forretningslag, hvor serviceorkestrering, hændelseshåndtering, regelhåndte-
ring 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 in-
frastruktur. 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). Drifts-
perioden forventes derfor alene at vare cirka 4 uger.
3) Løsningen er funktionelt begrænset i omfang i forhold til Kundens vision om en fremti-
dig 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 reduce-
ret omfang. Ikke desto mindre ønsker Kunden, at:
- Løsningens værdi kan afprøves. Derfor ønsker Kunden, at Løsningen skaber ad-
gang 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, funktio-
nalitet, 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, herun-
der som OIOXML
Kunden kan efter behov hente parameterbestemte udtræk af CPR-data fra Løs-
ningen under overholdelse af krav til sikkerhed, mv.
12
Løsningen adviserer automatisk om ændringer i lagrede CPR-data på specifice-
rede 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øt-
ter 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
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:
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 to-
taludtræ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 anven-des (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 funktio-
nelle 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 arkitek-
turprincipper, 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
14
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ændelsesadvi-
seringer. 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 infra-
struktur. Enkelte af de arkitekturkomponenter, der forventes at skulle indgå i en fremtidig
infrastruktur, skal imidlertid også indgå i Løsningen. Nedenfor illustreres de konkrete ar-
kitekturkomponenter, der tænkes realiseret til Løsningen. Komponenterne udgør en del-
mængde af de komponenter, der fremgår af Figur 3 Udkast til lagdelt arkitektur. Kompo-
nenter 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 udstil-
les i et servicekatalog. Det forventes også, at en portal er relevant i forbindelse med ad-
ministration. Løsningen skal kunne advisere Kunden om ændringer, hvilket kræver en
basal hændelseshåndtering. Desuden skal basale informationer logges for at tillade ba-
sal overvågning samt datagrundlag for afregning. Endeligt skal der være basal sikker-
hed.
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 for-
bindelse 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åndte-
res, der primært retter sig imod, at ændringer sker eksplicit og styres af kvalitets-
sikringsfunktionen i udviklingen.
16
4. Funktionelle behov
Krav til funktionalitet til Løsningen er i dette afsnit angivet som en behovsopgørelse. Be-
hovsopgø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 re-
levante 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. Beskri-
velsen 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 fre-
kvens, startbetingelser, aktører, overordnet forløb, og slutbetingelser. I beskri-
velsen 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 priori-
tet 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 Kun-
den.
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 data-
base med CPR-data.
Udstiller CPR-data til Løsningen
Driftsovervågning Repræsenterer et it- Overvåger løbende Løsningen og sik-
17
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 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øs-
ningen, jf. use case A2
Totaludtræk Det samlede aktuelle sæt af CPR-data, der er tilgængeli-
ge 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 for-
brugs- 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 An-
vendersystemet.
Use case A1 Foretag registerudtræk fra CPR-registret
Formål Løsningen kan foretage registerudtræk fra et CPR-
registret.
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øb 1. Løsningen henter et registerudtræk fra CPR-
registret (se Behov.Høj.01)
2. Der kvitteres for registerudtrækket (se Be-
hov.Høj.01).
3. Registerudtrækket transformeres (normaliseres),
indlæses og lagres i Løsningen (se Be-
hov.Høj.02, Behov.Høj.03, og Behov.Høj.04).
4. Ændringer til totaludtræk beregnes (se Be-
hov.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.
18
Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A1.
AnvendersystemLøsningenCPR-registeret
Hent udtrækOverfør udtræk
Validering af modtagelse
Normalisering af data
Beregn ændringer
Gem data og ændringer
Dan nyt totaludtræk og ændringer
Overfør adviseringom ændringer
Modtag adviseringom ændringer
Overfør advisering omny totaludtræk
Modtag advisering omnyt totaludtræk
Gør udtræk tilgængeligt for opslag
Håndter advisering
Håndter advisering
Send kvitteringModtag kvittering
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øs-
ningen 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øs-
ningen 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 over-
føres. Behov, der beskriver hvordan ændringsadviseringer håndteres er beskrevet i use
case B8.
Følgende overordnede behov er tilknyttet use case A1.
19
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 mod-
tages 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 registerud-træ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 automa-
tisk 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 totalud-
trækket, og automatisk sende adviseringer til Anvendersystemet, der abon-nerer 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. Des-
uden 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æn-
dringsudtræk fra CPR.registret.
Løsningen har tidligere indlæst et komplet regi-
sterudtræ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
20
Overordnet forløb 1. Løsningen henter et registerændringsudtræk fra
CPR-registret (se Behov.Høj.07).
2. Der kvitteres for modtagelse af registerændrings-
udtrækket (se Behov.Høj.07).
3. Registerændringsudtrækket normaliseres (stan-
dardiseres), 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 gene-
rere et nyt totaludtræk (se Behov.Høj.11).
5. Hvis Anvendersystemet har abonnement på æn-
dringer, adviseres det om ændringer i totalud-
træ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 Anven-
dersystemet.
Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A2.
CPR-registeret AnvendersystemLøsningen
Hent ændringerOverfør opdatering
Validering af modtagelse
Normalisering af ændringer
Beregn samlet datasæt
Gem data og ændringer
Dan nyt totaludtræk og ændringer
Send kvitteringModtag kvittering
Overfør adviseringom ændringer
Modtag adviseringom ændringer
Overfør advisering omny totaludtræk
Modtag advisering omnyt totaludtræk
Gør udtræk tilgængeligt for opslag
Håndter advisering
Håndter advisering
Figur 8 Use case A2: Modelskitse for registerændringsudtræk fra CPR-registret til Løsningen.
21
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øs-
ningen 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øsnin-
gen. 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 sik-
ker 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æn-dringsudtræk Løsningen kan transformere et registerændringsudtræk fra CPR-registret til
en normaliseret form. Det gælder også eventuelle metadata modtaget i for-bindelse 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æn-
dringsudtrækket og det nuværende totaludtræk. Behov.Høj.12. Advisering i forbindelse med modtagelse af registeræn-dringsudtræ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 An-
vendersystemet. Dette kan både ske på Anvendersystemets egen opfordring, og som
konsekvens af, at Anvendesystem er blevet adviseret om ændringer i totaludtrækket lag-
ret 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.
22
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
Overordnet forløb 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 Be-
hov.Høj.13).
4. Løsningen forbereder og overfører udtrækket til
Anvendersystemet (se Behov.Høj.14 og Be-
hov.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.
AnvendersystemLøsningen
Anmod om udtrækModtag anmodning
Send udtræk Modtag udtrækLog til afregning m.m.
Klargør udtræk til forsendelse
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øsnin-
gen. Løsningen modtager anmodningen om udtrækket og forbereder herefter udtrækket
til forsendelse, inden det sendes til Anvendersystemet. Samtidig hermed logges informa-
tioner om adgangen til data, samt forbrugsinformationer til en eventuel afregning.
Følgende overordnede behov er tilknyttet use case A3.
23
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 An-
vendersystemet. Behov.Høj.14. Overførsel af udtræk Løsningen kan 1) automatisk overføre det udtræk, Anvendersystemet an-
moder om, og 2) understøtte, at Anvendersystemet selv kan hente det ud-træ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 Anvendersyste-
met 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 ud-træ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 in-kluderes 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æsentati-
on. 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 register-
udtræ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 ind-
læses i Løsningen før videre behandling (se Be-
hov.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.
Behov.Høj.18. Indlæsning af registerudtræk Løsningen kan indlæse registerudtræk fra CPR-registeret, jf. specifikatio-
nen6. Behov.Høj.19. Indlæsning af registerændringsudtræk
Løsningen kan indlæse registerændringsudtræk fra CPR-registeret7.
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.
24
4.5 Use case B2: Udstil metadata
Det er væsentligt, at informationer om data (metadata) udstilles på Løsningen. Som mi-
nimum 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 regi-
steræ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 re-
gisterændringsudtræk, der inkluderer metadata
(se Behov.Høj.20, Behov.Alm.01).
2. I forbindelse med modtagelsen dannes automa-
tisk visse metadata (se Behov.Alm.04).
3. Ved udtræk af Anvendersystemet returneres re-
levante metadata, der er lagret sammen med ud-
træksdata (se Behov.Alm.02 og Behov.Alm.03).
Slutbetingelser Metadata er sammen med data leveret til Anvendersy-
stemet.
Følgende overordnede behov er tilknyttet use casen.
Behov.Høj.20. Metadata kan modtages i forbindelse med modtagelse af re-gisterudtræk eller registerændringsudtræk Løsningen kan modtage metadata sammen med registerudtræk og regi-
sterudtræ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 til-
bydes 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 ind-
gå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 ind-
gå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 identifi-kation 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 datakvalite-
ten er tilstrækkelig. Dette inkluderer validering af, at modtagelsen af registerudtræk og
25
registerændringsudtræk sker korrekt, at modtagne data er formateret korrekt, og at ind-
holdet 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æk-
kelig kvalitet.
Frekvens I forbindelse med modtagelse af registerudtræk og regi-
steræ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øb 1. Løsningen kontrollerer, at det overførte register-
udtræk eller registerændringsudtræk er overført
helt. Det vil sige, at der ikke mangler data (se Be-
hov.Høj.21, Behov.Høj.24 og Behov.Høj.25).
2. Løsningen kontrollerer, at registerudtrækket eller
registerændringsudtrækket overholder format-
specifikationerne 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æk-
ket eller registerændringsudtrækket overholder
dataspecifikationerne for CPR-data (se Be-
hov.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ørsel Løsningen understøtter specifikation og effektuering af en valideringsmeka-
nisme, 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 valideringsmeka-
nisme, 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 valideringsmeka-
niske, der kontrollerer, at modtagne data er indholdsmæssigt korrekte, her-under at en angivet dato faktisk er en korrekt dato (fx overholder antal dage i den pågældende måned).
26
Behov.Høj.24. Validering af CPR-formatet Lø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 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 Udtræk af logningsinformation
Formål At logningsinformation fra Løsningen kan gennemses og
behandles i et eksternt system.
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øb 1. Løsningen logger og lagrer opslag, modtagelse af
registerudtræk og registerændringsudtræk, over-
førsel af udtræk, mv. (se Behov.Høj.26).
2. Løsningen genererer et udtræk af logningsinfor-
mationer, og gør udtrækket tilgængeligt for eks-
terne systemer (se Behov.Høj.27).
Slutbetingelser Logningsudtræk kan inspiceres og indlæses i andre sy-
stemer 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ænge-lige 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.
27
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 afreg-
ningen 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
Startbetingelser Løsningen udstiller data til Anvendersystemer, jf. use ca-
se A3.
Aktører Løsningen
Overordnet forløb 1. Løsningen logger informationer om forbrug i for-
bindelse med alt ekstern anvendelse, som fx ved
anmodning om udtræk fra Løsningen (se Be-
hov.Alm.05).
2. Løsningen genererer et udtræk af forbrugsinfor-
mationer og gør udtrækket tilgængeligt for eks-
terne systemer (se Behov.Alm.06).
Slutbetingelser Forbrugsudtræk kan inspiceres og indlæses i Anvender-
system.
Følgende overordnede behov er tilknyttet use case B5.
Behov.Alm.05. Forbrugsinformationer Løsningen skal logge forbrugsinformationer omkring anvendelse af udstille-
de data, der tillader afregning efter forbrug, herunder tidspunkt, Anvender-system, 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 Anvendersy-stemet 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.
28
Use case B6 Administrer services
Formål At de services, der er udstillet på Løsningen, kan admini-
streres.
Frekvens Dagligt eller på nærmere specificeret tidspunkter
Startbetingelser Der findes en administrationsgrænseflade, der tillader
administration af services.
Aktører Løsningen, Administrator
Overordnet forløb 1. Administratoren kan administrere services, her-
under 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øsningen Løsningen kan administrere de services, der udstilles på Løsningen, herun-
der 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 konfi-guration 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 Admini-strator.
4.10 Use case B7: Driftsovervågning
Løsningen skal understøtte driftsovervågning af Løsningen, således at et driftsovervåg-
ningssystem 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 hensig-
ten og er operativ, samt at nedbrud af Løsningen kan op-
dages snarest muligt.
Frekvens Kontinuerligt.
Startbetingelser
Aktører Løsningen, Driftsovervågning
Overordnet forløb Driftsovervågningen er i stand til at forespørge Løsnin-
gen, om denne fungerer efter hensigten, idet Løsningen
udstiller en grænseflade med dette formål (se Be-
hov.Høj.30, Behov.Alm.09, og Behov.Alm.10).
Slutbetingelser Driftsovervågningen er orienteret om, hvorvidt Løsningen
29
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, auto-
matiseret 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 forbin-
delse 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 til-
meldinger om ændringsadviseringer, og afsende æn-
dringsadviseringer på baggrund af Anvendersystemets
tilmeldinger til ændringsadviseringer.
Frekvens Dagligt eller på nærmere specificeret tidspunkter
Startbetingelser Administration af tilmeldinger til ændringsadvise-
ringer er muligt.
Løsningen er i stand til at generere ændringsad-
viseringer i forbindelse med relevante ændringer i
totaludtrækket, jf. use case A1 og A2.
Aktører Løsningen, Anvendersystemet
Overordnet forløb 1. Det er muligt at administrere tilmeldinger til æn-
dringsadviseringer og angive parametre i forbin-
delse med tilmeldingen (se Behov.Høj.31, Be-
hov.Høj.32, Behov.Høj.33, og Behov.Høj.34).
2. Baseret på disse tilmeldinger foretager Løsningen
ændringsadviseringer i forbindelse med ændrin-
ger 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 ændringsadvise-
ringer, og Løsningen adviserer på baggrund af de ønske-
de tilmeldinger ved ændringer i totaludtrækket.
Følgende overordnede behov er tilknyttet use case B8.
30
Behov.Høj.31. Administration af tilmeldinger om ændringsadvisering Løsningen understøtter administration af tilmeldinger om ændringsadvise-
ring, 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 ændringsadvisering Løsningen understøtter angivelse af en frekvens for ændringsadviseringer.
Det vil sige, hvor ofte en advis skal sendes til et Anvendersystem, og at fre-kvensen for adviseringer kan oprettes, vises, ændres og slettes. Når Løs-ningen 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 ændringsadviseringer Løsningen understøtter konfiguration af metode for ændringsadviseringer,
fx at Anvendersystemet selv er ansvarlig for at kontrollere for og hente æn-dringsadviseringer, og at Løsningen er ansvarlig for at sende adviseringer til Anvendersystemet.
Behov.Høj.34. Overførselsprotokol for ændringsadviseringer Lø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 adviseringsdokument Løsningen understøtter, at Anvendersystemet selv henter adviseringsdo-
kumenter, der er gjort tilgængelige via Løsningen. Behov.Høj.37. Automatisk overførsel af adviseringsdokument Løsningen understøtter, at et genereret adviseringsdokument automatisk
overføres til Anvendersystemet. Behov.Alm.11. Advisering via webservice Løsningen understøtter, at et adviseringsdokument overføres via en web-
service, der udstilles af Anvendersystemet. Behov.Høj.38. Kvittering for ændringsadviseringer Løsningen understøtter kvittering for ændringsadviseringer, når 1) et An-
vendersystem 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ændringsud-
træk, jf. use case B1.
Startbetingelser
Aktører Løsningen
Overordnet forløb 1. Når et registerudtræk eller et registerændringsud-
31
træ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ændringsud-
træk er valideret og indlæst, lagres data i norma-
liseret form på et pålideligt medie, som fx en rela-
tionel database (se Behov.Høj.40, Behov.Høj.41,
og Behov.Høj.42).
Slutbetingelser Data fra registerudtrækket eller registerændringsudtræk-
ket er lagret permanent, og det kan tilbydes selvom Løs-
ningen skal genstartes.
Følgende overordnede behov er tilknyttet use case B9.
Behov.Høj.39. Persistering af registerudtræk og registerændringsudtræk Lø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 under-stø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. Behov.Høj.41. Persistering af metadata Lø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 konfiguration Løsningen kan persistere konfigurerbare elementer af services, fx konfigu-
rerede udtræksparametre eller konfiguration af metode for ændringsanvis-ninger.
32
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 (be-
skrevet i afsnit 4). De non-funktionelle krav til selve Løsningen er opdelt i følgende om-
rå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 til-
buddet ikke er konditionsmæssigt.
Krav Krav.Alm Leverandøren skal i udgangspunktet opfylde det-
te krav og leverandørens opfyldelse af kravet ind-
går i vægtning af Leverandørens tilbud. Manglen-
de eller delvis opfyldelse vil ikke betyde, at tilbud-
det 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 Kun-
den, forventes det, at Løsningen designes således, at den opfylder en række krav til arki-
tektur, som Kunden forudser vil skulle anvendes for Kundens fremtidige infrastruktur.
Kunden ønsker en arkitektur for Løsningen, der er baseret på serviceorientering. Funkti-
onalitet til brugere af Løsningen skal udstilles som services. IT og Telestyrelsen har i for-
bindelse med IT arkitekturarbejde udgivet en pjece om serviceorienteret arkitektur9, der
skal danne grundlag for arkitekturen i Løsningen, herunder serviceorienteringen, i Løs-
ningen.
Kunden ønsker en fleksibel arkitektur for Løsningen, der tillader, at Løsningen omkost-
ningseffektivt 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 re-
9 http://www.itst.dk/it-arkitektur-og-standarder/it-arkitektur/serviceorienteret-arkitektur-serviceorienteret-
infrastruktur/serviceorienteret-arkitektur/soa/Pjece_Serviceorienteret_arkitektur.pdf
33
gistre 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 kil-
dekoden.
Krav.Alm.01. Arkitekturkrav Løsningen skal anvende en serviceorienteret arkitektur, der er fleksibel og
skalerbar. Krav.Alm.02. Offentlige standarder Løsningen skal anvende relevante fællesoffentlige standarder. Særligt rele-
vant er, at CPR-data i videst muligt omfang stilles til rådighed for Anvender-systemet 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ær-mere defineret i kontrakten.
Krav.Alm.04. Standardkomponenter I det omfang der forefindes egnede, robuste og afprøvede standardkompo-
nenter, 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, herun-
der 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 vareta-
ges af autoriserede personer (Administratorer). Adgang til CPR-data, der udstilles på
Løsningen, skal ligeledes kunne kontrolleres, således at Kunden kan opfylde Personda-
taloven 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 Sikker-
hedsbekendtgørelsen er Kundens ansvar.
Krav.Min.01. Sikkerhedsarkitektur 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 DS484 Leverandørens sikkerhedspolitik skal være udformet, så de "tekniske dele"
af DS484 (inkl. den del der vedrører behandling af personfølsomme oplys-ninger), er opfyldt.
Krav.Min.02. Overholdelse af persondataloven Løsningen skal understøtte, at Kunden kan behandle personoplysninger i
henhold til persondataloven, herunder Sikkerhedsbekendtgørelsen, Datatil-
34
synets praksis vedrørende behandling af person oplysninger og i overens-stemmelse med god databehandlingsskik.
Krav.Min.03. Sletning af data Løsningens arkitektur skal sikre, at det er muligt at slette alle data i Løsnin-
gen. Krav.Alm.06. Rollebaseret adgangskontrol til Løsningen Lø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æn-delser Løsningen skal implementere sporbarhed i brugeraktiviteter og sikkerheds-
relaterede hændelser. Dette kan fx realiseres via logning af brugeraktiviteter på forretningsniveau der kan spores til den enkelte bruger og dennes place-ring (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 data Løsningen skal sikre, at al adgang til CPR-data er kontrolleret, før adgan-
gen 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 data Lø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 kon-figureres til at sikre logning af adgang for alle udstillede services.
Krav.Alm.09. Adgangskontrol integreret til brugerregister Løsningen skal kunne integrere kontrol af adgang til Løsningen til et bruger-
register, 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 videreudvikles Løsningens design og struktur skal være således, at den kan videreudvikles
og vedligeholdes løbende. Løsningens design og struktur skal tillade rettel-ser 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.
Krav.Alm.10. Portabilitet omkring driftsplatforme Løsningen skal kunne installeres på og porteres til forskellige driftsplatfor-
me, 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 standardkomponenter Lø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 da-tabaser, der opfylder en tilstrækkelig grad af SQL-standarder.
35
5.5 Effektivitet og skalering
Løsningen under Kontrakten skal tilgås af et enkelt Anvendersystem hos Kunden (An-
vendersystemet). 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 urime-
ligt 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ængder Lø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. Skalering Lø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 doku-
mentation og afsnit 6.4 for servicemål for Løsningen.
Krav.Alm.13. Robusthed Lø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øsningen Det 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.
Krav.Alm.15. Overvågning Løsningen understøtter overvågning af Løsningen fra et driftsovervågnings-
system, således at driftscenteret løbende kan verificere, at Løsningen fun-gerer efter specifikationerne og er tilgængelig.
Krav.Alm.16. Driftslogning Løsningen foretager driftslogning af alle afviklede programmer og kompo-
nenter, således at det er muligt at overvåge at al afvikling foregår efter spe-cifikationerne, og at det giver mulighed for reaktion såfremt fejl opstår.
Krav.Alm.17. Fejlhåndtering Lø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.
36
Krav.Alm.18. Automatisk backup Løsningen kan konfigurere automatisk backup af konfigurationsdata og da-
ta, således at hurtig reetablering af Løsningen inklusive dens data er muligt.
37
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 vi-ser de tre typer dokumentation, som skal leveres under Kontrakten
Type Beskrivelse
Systemdokumentation Betegner dokumentation, der beskriver Løsningens kon-
struktion 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 net-
værkskomponenter, værktøjer og systemer, der anven-
des, og de procedurer, der skal følges.
Brugerdokumentation Betegner dokumentation, der er rettet imod anvendelsen
af Løsningen. Herunder regnes dokumentation, der tilla-
der adgang til data udstillet af Løsningen, og dokumen-
tation, 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 redigeres Al dokumentation skal afleveres i elektronisk og redigerbar form. Krav.Alm.20. Dokumentation skal være aktuel Al dokumentation skal til enhver tid afspejle den løsning, der leveres til
Kunden, med tydelig versionsangivelse.
6.1.2 Krav til systemdokumentation
Nedenfor præsenteres de specifikke krav til systemdokumentationen, der udgøres af ar-
kitekturdokumentation, designdokumentation, grænsefladedokumentation, databasedo-
kumentation samt udviklings- og vedligeholdelsesdokumentation.
Krav.Min.07. Krav til systemdokumentation Leverandøren skal levere systemdokumentation, der omfatter alle relevante
dele af Løsningen. Krav.Min.08. Arkitekturdokumentation
38
Leverandøren skal levere løsnings- og arkitekturdokumentation, der beskri-ver Løsningens komponenter og disses interaktioner.
Krav.Alm.21. Designdokumentation Leverandøren skal levere designdokumentation, der beskriver design og re-
levante dele af implementeringen af kundespecifikt programmel. Krav.Alm.22. Grænsefladedokumentation Leverandøren skal levere dokumentation af udstillede grænseflader, der
beskriver eventuelle protokoller og dataformater, der skal anvendes. Krav.Alm.23. Databasedokumentation Leverandøren skal levere dokumentation af anvendelsen af databaser, her-
under skemaer, tabeller, stored procedures og views. Krav.Min.09. Udviklings- og vedligeholdelsesdokumentation Leverandøren skal levere udviklings- og vedligeholdelsesdokumentation,
der sikrer mulighed for overdragelse til tredjepart af udvikling og vedlige-hold.
6.1.3 Krav til driftsdokumentation
Nedenfor præsenteres de specifikke krav til driftsdokumentation, der udgøres af driftsar-
kitekturdokumentation, installationsdokumentation, dokumentation af opsætning, admini-
strationsdokumentation, og etablerings- og vedligeholdelsesdokumentation. Krav til etab-
lering og drift er specificeret i afsnit 6.2.
Krav.Min.10. Driftsarkitekturdokumentation Leverandøren skal levere dokumentation af driftsarkitekturen af de syste-
mer, der sættes i drift (udviklingsmiljø og testmiljø), herunder eventuelle for-udsætninger om driftsmiljøet, fx netværk og servere, således at Kunden har mulighed for at skifte driftsplatform.
Krav.Min.11. Installationsdokumentation Leverandøren skal levere dokumentation af installation og konfiguration, så
Løsningen kan installeres og konfigureres korrekt i udviklingsmiljø og test-miljø.
Krav.Alm.24. Konfigurationsdokumentation Leverandøren skal levere dokumentation af konfiguration, herunder af even-
tuelle batch jobs til databaser, skedulerede jobs, og konfiguration af bruger-profiler til udviklingsmiljø og testmiljø.
Krav.Alm.25. Administrationsdokumentation Leverandøren skal levere tilstrækkelig dokumentation til, at Løsningen kan
administreres i drift i udviklingsmiljø og testmiljø, herunder sikkerhedsadmi-nistration (styring af adgangsrettigheder), opstart og nedlukning af Løsnin-gen, og andre systemspecifikke procedurer.
Krav.Alm.26. Vedligeholdelsesdokumentation Leverandøren skal levere dokumentation af vedligehold af Løsningen, her-
under procedurer for backup og restore. Krav.Alm.27. Overvågningsdokumentation Leverandøren skal levere dokumentation af, hvordan Løsningen understøt-
ter 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 do-
kumentation, der tillader adgang til data udstillet af Løsningen, og dokumentation, der til-
39
lader tredjepart at udvikle nye komponenter på den etablerede platform. Krav til overdra-
gelse fremgår af afsnit 6.3.
Krav.Alm.28. Krav til brugerdokumentation Leverandøren skal levere brugerdokumentation, der på nem og overskuelig
vis tillader Kunden at anvende Løsningen. Krav.Alm.29. Dokumentation til udvikling Leverandø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. Ind-ledningsvist 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 udstil-ler 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 overhol-der 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.
Etableres af Leverandøren
Anvendersystem (it-system hos Kunden)
CPR
@
TestUdvikling Testklient
CPR DataCPR Data
Figur 10 Oversigt over it-systemer i forbindelse med Løsningen.
40
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 si-ge et udviklingsmiljø og et testmiljø etableres, sammen med en sikret forbindelse til In-ternettet 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 Leve-
randøren.
Krav.Alm.30. Adgang til CPR-registeret Løsningen skal som sikker FTP-klient kunne tilgå CPR-registerets FTP ser-
ver, for at hente registerudtræk og registerændringsudtræk, og i denne for-bindelse overhold CPR-registerets krav til adgang, fra både udviklingsmiljø-et og testmiljøet.
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 Kunden Lø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æk Det skal være muligt for Kunden via Anvendersystemet at hente eller an-
mode om et udtræk fra Løsningen indeholdende såvel CPR-data, metadata eller logningsinformation.
Krav.Alm.32. Advisering om ændringer Lø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 for-ventes at etablere et testmiljø og udviklingsmiljø.
Krav.Min.13. Etablering af udviklingsmiljø
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.
41
Leverandøren skal etablere et udviklingsmiljø hvor Løsningen kan installe-res 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 kon-
trolleret 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-PC Leverandø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 for-stå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 platform Løsningen skal kunne afvikles på en virtualiseret platform. Såfremt Løsnin-
gens effektivitet kan forbedres væsentligt ved at stille særlige krav til virtua-liseringen eller ved at undlade at anvende virtualisering for hele eller dele af Løsningen, skal dette eksplicit angives af Leverandøren.
Krav.Min.16. Drift af Løsningen Leverandøren skal levere drift af Løsningen på udviklingsmiljøet og testmil-
jøet indtil gennemført og godkendt Driftsprøve. Krav.Alm.35. Backup og restore Leverandøren skal levere backup af Løsningen, og af konfigurationsdata og
data, der er indlæst i løsningen. Leverandøren skal kunne restore (gendan-ne) 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 tred-
jepart. Det skal ligeledes være muligt for tredjepart at udvikle komponenter, der kan ud-
stilles og afvikles på Løsningen. Dette skal primært sikres ved at overdrage kildekoden
og eventuelt konfigurationsmateriale af Standardprogrammel til Kunden og gennem rele-
vant dokumentation, jf. underafsnit 6.1.
Krav.Min.17. Overdragelse til tredjepart Det skal være muligt for Kunden at overdrage drift, vedligehold og videre-
udvikling af Løsningen til tredjepart efter levering af Løsningen. Som mini-mum skal kildekode til Kundespecifikt programmel og al relevant konfigura-tionsmateriale af komponenter leveres til Kunden i en stand, der gør Kun-den i stand til at få tredjepart til at drifte, vedligeholde og videreudvikle Løs-ningen.
42
6.4 Servicemål til Driftsprøve
I nærværende afsnit har Kunden angivet sine krav i forbindelse med Løsningens ser-vicemå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 adgangs-vindue
Mandag til fredag fra 08:00 til 18:00
Almindelig driftsperiode, hvor Løsningen er til-gængeligt for Kundens Anvendersystem.
Batchvindue Mandag til søndag fra 22:00 til 04:00
Driftsperiode, hvor Løs-ningen 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 Leve-randøren må påvirke mil-jøet, herunder medføre at elementer heraf er midlertidigt utilgængeli-ge.
Tabel 1 Definition af tidsvinduer
Krav.Alm.36. Almindelig Kundeadgang Løsningen skal være tilgængelig for Anvendersystemet i 98 % af tiden i Al-
mindeligt adgangsvindue, jf. Tabel 1 Definition af tidsvinduer. Krav.Alm.37. Batchkørsel Løsningen skal være tilgængelig for registerudtræk og registerændringsud-
træ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. Servicevinduet Leverandøren kan frit lukke for adgang til Løsningen for at opdatere Løs-
ningen i servicevinduet, jf. Tabel 1 Definition af tidsvinduer. Leverandøren kan ikke lukke for adgangen eller opdatere Løsningen uden for Servicevin-duet 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æn-dringsudtræ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 mak-simum 25.000.
43
Der er følgende krav til svartider.
Krav.Alm.39. Svartid for indlæsning af registerudtræk fra CPR-registret Løsningen skal være i stand til at modtage, validere og kvittere for et kom-
plet 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ørs-lens 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 totalud-træ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 totalud-trækket er tilgængeligt for Anvendersystemet.
Krav.Alm.41. Svartid for advisering af Anvendersystemet om ændringer Efter 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 tids-rummet mellem sluttidspunktet for indlæsning af udtrækket eller ændrings-udtrækket og starttidspunktet, hvor adviseringer sendes til Anvendersyste-mer. Forsinkelsen på eventuelle netværk medregnes ikke.
Krav.Alm.42. Svartid for overførsel af udtræk til Kunden Under 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 og sluttidspunkt for overførslen. Forsinkelsen på eventuelle netværk med-regnes ikke.
Krav.Alm.43. Reetableringstid for Løsningen Reetablering 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.
