BILAG 2 KRAVSPECIFIKATION
|
|
- Tilde Hedegaard
- 8 år siden
- Visninger:
Transkript
1 4. februar 2011 BILAG 2 KRAVSPECIFIKATION KOMBIT A/S Halfdansgade København S
2 Indholdsfortegnelse 1. Vejledning til Leverandøren Kravspecifikationens indhold Om selve kravspecifikationen Besvarelse af kravspecifikationen Baggrund Kort om Kunden Forretningsbehov for fremtidig infrastruktur Løsningsarkitektur for fremtidig infrastruktur Overordnede arkitekturprincipper for fremtidig infrastruktur Arkitekturkomponenter til fremtidig infrastruktur Løsningen Løsningens arkitektur og funktionalitet CPR-data Use cases til Løsningen Overordnede arkitekturprincipper Arkitekturkomponenter It-miljøer Funktionelle behov Use case A1: Foretag registerudtræk fra CPR-registret Use case A2: Foretag registerændringsudtræk fra CPR-registret Use case A3: Overfør udtræk Use case B1: Indlæsningsformater Use case B2: Udstil metadata Use case B3: Validering og sikring af datakvalitet
3 4.7 Use case B4: Udtræk af logningsinformation Use case B5: Udtræk af forbrugsinformation Use case B6: Administrer services Use case B7: Driftsovervågning Use case B8: Administrer og afsend ændringsadviseringer Use case B9: Persistering (lagring) af data Non-funktionelle krav Arkitekturprincipper Sikkerhed Vedligeholdelse og videreudvikling Portabilitet Effektivitet og skalering Pålidelighed og tilgængelighed Relaterede ydelser Dokumentation Etablering og drift af test- og udviklingsmiljø Overdragelse Servicemål til Driftsprøve
4 1. Vejledning til Leverandøren Dette bilag udgør Kundens kravspecifikation til Løsningen og relaterede ydelser, herunder dokumentation, drift samt servicemål. Dermed udgør dette bilag i sammenhæng med underbilag 2A, Leverandørens beskrivelse af Løsningen og relaterede ydelser, og underbilag 2B, Behovs- og kravsopfyldelse, den samlede beskrivelse af Løsningen og relaterede ydelser. Leverandøren skal ikke udfylde dette bilag, men besvare bilaget gennem udfyldelse af underbilag 2A, Leverandørens beskrivelse af Løsningen og relaterede ydelser, og underbilag 2B, Behovs- og kravsopfyldelse. 1.1 Kravspecifikationens indhold Bilaget er udformet som følger. Afsnit 1 er en kort beskrivelse af indholdet af bilag 2 og underbilagene til dette, samt hvordan Leverandøren udfylder disse. Afsnit 2 er et baggrundsafsnit, der kort introducerer Kunden og Kundens behov for en fremtidig infrastruktur. Dette afsnit er alene baggrundsviden og beskriver ikke Løsningen, der skal leveres under Kontrakten. Afsnit 3 beskriver på et overordnet niveau, hvad Løsningen består af, hvilken kontekst den skal indgå i, og hvilke forventninger Kunden har til funktionalitet og arkitektur. Afsnit 4 angiver Kundens funktionelle behov til Løsningen. Afsnit 5 angiver Kundens non-funktionelle krav til Løsningen. Afsnit 6 angiver Kundens krav til relaterede ydelser, herunder dokumentation, drift og vedligehold, samt servicemål Kravspecifikationen er udformet med vekslende tekstuel beskrivelse af behov og krav og de relevante behov og krav. 1.2 Om selve kravspecifikationen Der skelnes mellem behov og krav. I det følgende listes de anvendte typer behov og krav. Behov er defineret ved nedenstående typer. Behovsprioritet Betegnelse Beskrivelse Høj Behov.Høj Det pågældende behov har høj prioritet og vurderes at være nødvendigt for Løsningen. Almindelig Behov.Alm Det pågældende behov har almindelig prioritet og vurderes at være ønskværdig men ikke nødvendig for Løsningen. Leverandørens opfyldelse af behov med høj prioritet vægtes højere end opfyldelse af behov med almindelig prioritet. Der er ingen behov, som skal opfyldes for, at Leverandørens tilbud er konditionsmæssigt. 4
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 opfyldelse omfatter. Hvis ikke Leverandøren indsætter en kommentar vurderes behovet som Ikke opfyldt. Krav er defineret ved nedenstående typer. Kravs type Betegnelse Kravs opfyldelse Mindstekrav Krav.Min Leverandøren skal opfylde dette krav. Manglende opfyldelse eller delvis opfyldelse vil betyde, at tilbuddet ikke er konditionsmæssigt. Krav Krav.Alm Leverandøren skal i udgangspunktet opfylde dette krav og leverandørens opfyldelse af kravet indgår i vægtning af Leverandørens tilbud. Manglende eller delvis opfyldelse vil ikke betyde, at tilbuddet er ukonditionsmæssigt, men vil tælle ned i bedømmelsen af Leverandørens tilbud. De krav som Kunden finder uundværlige for Løsningen, har prioritet af Mindstekrav. De almindelige krav er væsentlige for Løsningen, men ikke nødvendige. Kan Leverandøren eller dennes løsning delvis imødekomme det pågældende krav, angives Delvist opfyldt. Angives Delvist opfyldt, vurderes dette som et forbehold og Leverandøren skal i kommentarfeltet specificere, hvad forbeholdet for kravets opfyldelse omfatter. Hvis ikke Leverandøren indsætter en kommentar vurderes kravet som Ikke opfyldt. Alle krav er angivet med et fortløbende nummer. 1.3 Besvarelse af kravspecifikationen Leverandøren besvarer kravspecifikationen ved at udfylde underbilag 2A, Leverandørens beskrivelse af Løsningen og relaterede ydelser, og underbilag 2B, Behovs- og kravsopfyldelse I underbilag 2A skal Leverandøren vise, hvordan dennes løsning lever op til Kundens behov og krav. En vejledning om udarbejdelse findes i underbilaget. I underbilag 2B skal Leverandøren angive, i hvilket omfang dennes løsning opfylder Kundens behov og krav som vist i skemaet nedenfor. En vejledning om udarbejdelse findes ligeledes i underbilaget. 5
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 6
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. 7
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. 8
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 arkitekturprincipper Arkitekturkomponenter til fremtidig infrastruktur I tillæg til ovenstående arkitekturprincipper forventes den fremtidige infrastruktur baseret på en lagdelt, service-baseret arkitektur. Nedenfor er en skitse for en sådan lagdelt, service-baseret arkitektur Figur 3 Udkast til lagdelt arkitektur. Som Figur 3 illustrerer, tænkes i følgende lag: Systemadgang, der er ansvarlig for at give adgang til udtræk eller til systemer. Disse systemer har egne grænseflader, hvorfor adaptere 3 skal anvendes for tilgang til disse systemer. Servicekomponenter, der er genbrugelige komponenter, der anvendes i alle de services, der udstilles via platformen, fx til brugerstyring, logning, og sikkerhed. Data integration og service implementering, der er ansvarlig for at definere en standardiseret datamodel og standardiserede grænseflader. Enterprise service bus, der udstiller services og styrer adgangen til disse Adaptere er integrationskomponenter der tillader adgang fra et system til et andet, og hvor adgangen kræver tilpasning. Dette kan fx være en database adapter, der giver adgang til forskellige databaser, og hvor umiddelbare forskelle i de underliggende databaser skjules for anvenderen af adapteren. 9
10 Forretningslag, hvor serviceorkestrering, hændelseshåndtering, regelhåndtering og monitorering håndteres, samt eventuelle brugergrænseflader udstilles. 10
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 Løsningen baserer sig på en række af de arkitekturprincipper, som Kunden forventer at bygge den fremtidige infrastruktur på. Kundens forventninger til arkitektur, funktionalitet, mv. gennemgås i underafsnit 3.3, 3.4, 3.5 og 3.6. De konkrete behov og krav fremgår af afsnit 4 og 5. Indledningsvist gennemgås Kunden overordnede forventninger til Løsningens arkitektur og funktionalitet. 3.1 Løsningens arkitektur og funktionalitet Overordnet forventer Kunden, at: Løsningen kan foretage registerudtræk og registerændringsudtræk af CPR-data fra CPR-registret Løsningen kan lagre udtrukne CPR-data på en måde, der sikrer, at Løsningen lagrer et aktuelt totaludtræk Løsningen kan udstille lagrede CPR-data på sikker og standardiseret vis, herunder som OIOXML Kunden kan efter behov hente parameterbestemte udtræk af CPR-data fra Løsningen under overholdelse af krav til sikkerhed, mv. 11
12 Løsningen adviserer automatisk om ændringer i lagrede CPR-data på specificerede intervaller, fx ugentligt Løsningen etableres i et udviklingsmiljø og et testmiljø hos Leverandøren, som Leverandøren skal drifte, indtil Driftsprøven er gennemført. Nedenstående figur viser løsningsarkitekturen for Løsningen. Her fremgår det, at figuren er en begrænset version af Figur 2 Løsningskoncept., underafsnit 2.3. Figur 4: Omfanget af Løsningen. Funktionalitet inkluderer Logning, overvågning og forbrugsmåling til afregning, samt et servicekatalog og basal sikkerhed. Dertil kommer funktionalitet til selve CPR-servicen. Der forventes ikke brugerstyring. 3.2 CPR-data I dette underafsnit gives en tekstuel beskrivelse af, hvordan Løsningen skal tilgå og stille CPR-data til rådighed. De konkrete behov til dette fremgår af afsnit 4. CPR-data vil blive gjort tilgængelige på CPRs-dataserver som udtræk. Denne understøtter sikker FTP-forbindelse, SSH og Netview FTP 4. Til Løsningen anvendes sikker FTP (RFC 4217). CPR-registret udstiller både fulde registerudtræk og registerændringsudtræk, der kan hentes fra deres server 5. Data kan udtrækkes i et format med records af forskellige typer med faste feltbredder. 4 Levering af data, på siden Testdata til udtræk, på siden samt specifikt om filtransmission her: 5 Jf. Testdata til udtræk, på siden samt specifikt om filtransmission her: 12
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 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 u12180-p pnr nøgler off valgfrie recordtyper.pdf, tilgængelig fra siden Jf. u12170-p ændringsudtræk off valgfrie recordtyper.pdf, tilgængelig fra siden 13
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ændelsesadviseringer. Services skal være indkapslet, således at et anvendersystem af en service ikke skal være bekendt med, hvordan servicen er implementeret for at anvende den. Løsningen skal være fleksibel, således at den kan interagere og samarbejde med andre systemer. Løsningen skal understøtte relevante fællesoffentlige standarder, herunder OIOgodkendte standarder. I det omfang yderligere standarder er relevante, skal de ligeledes anvendes. Løsningen skal i videst mulig omfang anvende modne teknologier. Det vil sige, at afprøvede komponenter foretrækkes frem for nyere. Komponenter baseret på open source-licens foretrækkes frem for kommercielle komponenter. 3.5 Arkitekturkomponenter Nedenfor gives en tekstuel beskrivelse af, hvilke arkitekturkomponenter der skal indgå i Løsningen. En fuldstændig behovsopgørelse fremgår af afsnit 4. Løsningen er begrænset i omfang i forhold til, hvad der tænkes i den fremtidige infrastruktur. Enkelte af de arkitekturkomponenter, der forventes at skulle indgå i en fremtidig infrastruktur, skal imidlertid også indgå i Løsningen. Nedenfor illustreres de konkrete arkitekturkomponenter, der tænkes realiseret til Løsningen. Komponenterne udgør en delmængde af de komponenter, der fremgår af Figur 3 Udkast til lagdelt arkitektur. Komponenter markeret med X indgår ikke i Løsningen. Figur 6 Forventede arkitekturkomponenter i Løsningen. 14
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. 15
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. Nonfunktionelle krav fremgår af afsnit 5. Først gives en vejledning til behovsopgørelsen og en introduktion til relevant terminologi, der skal anvende Løsningen, inden behovene til de enkelte use cases præsenteres. Vejledning til behovsopgørelsen I behovsopgørelsen angives de funktionelle behov til Løsningens understøttelse af de relevante use cases, som identificeret på Figur 5. For hver use case gives en overordnet beskrivelse samt en liste af identificerede behov, der er relateret til beskrivelsen. Beskrivelsen af hver use case følger denne struktur: Use casen beskrives tekstuelt. De mere komplekse use cases beskrives på struktureret form i en tabel med frekvens, startbetingelser, aktører, overordnet forløb, og slutbetingelser. I beskrivelsen af det overordnede forløb anvendes referencer til de konkrete behov. For use casene med flere aktører (A1, A2 og A3) er tillige et aktivitetsdiagram. Konkrete behov, der er identificeret i forbindelse med hver use case, angives med følgende to typer behovsprioritering: Behovsprioritet Betegnelse Beskrivelse Høj Behov.Høj Det pågældende behov har høj prioritet og vurderes at være nødvendigt for Løsningen. Almindelig Behov.Alm Det pågældende behov har almindelig prioritet og vurderes at være ønskværdig men ikke nødvendig for Løsningen. Leverandørens opfyldelse af behov med høj prioritet vægtes højere end opfyldelse af behov med almindelig prioritet. Der er ingen behov, som skal opfyldes for, at Leverandørens tilbud er konditionsmæssigt. Terminologi I såvel funktionelle behov og non-funktionelle og øvrige krav indgår nedenstående aktører. Rolle Beskrivelse Opgaver Anvendersystem Et eller flere it-systemer hos Kunden. Abonnerer på og udtrækker data fra Løsningen Administrator En fysisk bruger hos Kunden. Udfører administration i forbindelse med Løsningen. Tilgår ikke de data, Løsningen udstiller. CPR-registret CPR-registret eller anden Udstiller CPR-data til Løsningen af Kunden udpeget database med CPR-data. Driftsovervågning Repræsenterer et it- Overvåger løbende Løsningen og sik- 16
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 Registerudtræk Registerændringsudtræk Totaludtræk (Øvrige) udtræk Beskrivelse Initielt dumpudtræk fra CPR-registret til Løsningen, jf. use case A1. Løbende udtræk af ændringer fra CPR-registret til Løsningen, jf. use case A2 Det samlede aktuelle sæt af CPR-data, der er tilgængelige i Løsningen. Beregnes på baggrund af registerudtræk og registerændringsudtræk, således at det afspejler de seneste CPR-oplysninger i CPR-registret. Alle udtræk fra Løsningen til Anvendersystemet. Udtræk kan udgøre en delmængde af totaludtrækket, samt forbrugs- og logningsinformation. 4.1 Use case A1: Foretag registerudtræk fra CPR-registret I denne use case skal Løsningen udtrække og lagre CPR-data, så data kan stilles til rådighed for Anvendersystemet. Desuden skal Anvendersystemet adviseres om ændringer i CPR-data. Løsningen skal altså understøtte registerudtræk fra CPR-registret, herunder at data fra dette registerudtræk lagres i Løsningen, samt understøtte advisering af Anvendersystemet. Use case A1 Foretag registerudtræk fra CPR-registret Formål Løsningen kan foretage registerudtræk fra et CPRregistret. Frekvens Dagligt eller på nærmere specificeret tidspunkt Startbetingelser Kunden har etableret en aftale om registerudtræk fra CPR-registret. Der kan eksistere tilmeldinger til adviseringer om ændringer i totaludtræk, jf. use case B8. Aktører Overordnet forløb Slutbetingelser Løsningen, CPR-registret, Anvendersystemet 1. Løsningen henter et registerudtræk fra CPRregistret (se Behov.Høj.01) 2. Der kvitteres for registerudtrækket (se Behov.Høj.01). 3. Registerudtrækket transformeres (normaliseres), indlæses og lagres i Løsningen (se Behov.Høj.02, Behov.Høj.03, og Behov.Høj.04). 4. Ændringer til totaludtræk beregnes (se Behov.Høj.05) 5. Anvendersystemer, der abonnerer på ændringer, adviseres om ændringer (se Behov.Høj.06). Løsningen har kvitteret for gennemført registerudtræk, adviseringer er overført, og det ny totaludtræk er udstillet til Anvendersystemet. 17
18 Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A1. CPR-registeret Løsningen Anvendersystem Overfør udtræk Hent udtræk Validering af modtagelse Modtag kvittering Send kvittering Normalisering af data Beregn ændringer Gem data og ændringer Dan nyt totaludtræk og ændringer Overfør advisering om ændringer Modtag advisering om ændringer Håndter advisering Gør udtræk tilgængeligt for opslag Håndter advisering Overfør advisering om ny totaludtræk Modtag advisering om nyt totaludtræk Figur 7 Use case A1: Modelskitse for registerudtræk fra CPR-registret til Løsningen. Som vist på Figur 7 foretager Løsningen et (nyt) registerudtræk fra CPR-registret. Løsningen validerer overførslen med en kontrol af, om overførslen er komplet, og om det grundlæggende format for overførslen er overholdt. Herefter må det forventes, at Løsningen skal kvittere for overførslen til CPR-registret. Løsningen foretager en transformation af data, således at Løsningen herefter håndterer data på en normaliseret (standardiseret) form. Baseret på den normaliserede form kan eventuelle ændringer til data beregnes, og disse ændringer lagres sammen med data i Løsningen. Herefter kan et nyt sæt totaldata Det vil sige den samlede datamængde for hele dataområdet dannes og gøres tilgængeligt for udtræk. Sideløbende med at gøre det samlede sæt totaldata tilgængeligt, kan adviseringer overføres. Behov, der beskriver hvordan ændringsadviseringer håndteres er beskrevet i use case B8. Følgende overordnede behov er tilknyttet use case A1. 18
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 modtages af Løsningen, er overført korrekt, jf. use case B3. Behov.Høj.03. Indlæsning af registerudtræk Løsningen kan indlæse et registerudtræk fra CPR-registeret som en fil i Løsningen, jf. use case B1. Behov.Høj.04. Transformering i forbindelse med modtagelse af registerudtræk Løsningen kan transformere alle data i registerudtræk fra CPR-registret til en normaliseret form. Det samme gælder eventuelle metadata, der overføres i forbindelse med registerudtrækket. Løsningen skal understøtte, at transformationen benytter tabeller og algoritmer, og at disse kan lagres i Løsningen. Behov.Høj.05. Beregn ændringer i forhold til tidligere registerudtræk Løsningen kan på baggrund af tidligere modtagne registerudtræk automatisk beregne ændringer til totaludtræk. Behov.Høj.06. Advisering i forbindelse med modtagelse af registerudtræk Løsningen kan automatisk generere adviseringer om ændringer i totaludtrækket, og automatisk sende adviseringer til Anvendersystemet, der abonnerer på ændringer, jf. use case B Use case A2: Foretag registerændringsudtræk fra CPR-registret Løsningen skal understøtte, at Løsningen modtager et registerændringsudtræk fra CPRregistret, og at relevante data lagres i Løsningen. I denne use case skal Løsningen på baggrund af ændringsudtrækket fra CPR-registret foretage en opdatering af det lagrede totaludtræk, så et aktuelt totaludtræk kan stilles til rådighed for Anvendersystemet. Desuden skal Anvendersystemet adviseres, hvis det har abonnement på ændringer. Use case A2 Foretag registerændringsudtræk fra CPR-registret Formål Løsningen kan foretage registerændringsudtræk fra CPRregistret. Frekvens Dagligt eller på nærmere specificeret tidspunkt Startbetingelser Kunden har etableret en aftale om registerændringsudtræk fra CPR.registret. Løsningen har tidligere indlæst et komplet registerudtræk fra CPR-registret, jf. use case A1. Der kan eksistere tilmeldinger til adviseringer om ændringer i totaludtrækket, jf. use case B8. Aktører Løsningen, CPR-registret, Anvendersystemet 19
20 Overordnet forløb Slutbetingelser 1. Løsningen henter et registerændringsudtræk fra CPR-registret (se Behov.Høj.07). 2. Der kvitteres for modtagelse af registerændringsudtrækket (se Behov.Høj.07). 3. Registerændringsudtrækket normaliseres (standardiseres), indlæses og lagres i Løsningen (se Behov.Høj.08, Behov.Høj.09, og Behov.Høj.10). 4. Registerændringsudtrækket anvendes til at generere et nyt totaludtræk (se Behov.Høj.11). 5. Hvis Anvendersystemet har abonnement på ændringer, adviseres det om ændringer i totaludtrækket(se Behov.Høj.12). Løsningen har kvitteret for modtagelse, adviseringer er overført, og et nyt totaludtræk er tilgængeligt for Anvendersystemet. Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A2. CPR-registeret Løsningen Anvendersystem Overfør opdatering Hent ændringer Validering af modtagelse Modtag kvittering Send kvittering Normalisering af ændringer Beregn samlet datasæt Gem data og ændringer Dan nyt totaludtræk og ændringer Overfør advisering om ændringer Modtag advisering om ændringer Håndter advisering Gør udtræk tilgængeligt for opslag Håndter advisering Overfør advisering om ny totaludtræk Modtag advisering om nyt totaludtræk Figur 8 Use case A2: Modelskitse for registerændringsudtræk fra CPR-registret til Løsningen. 20
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øsningen skal kvittere for overførslen til CPR-registret. Løsningen foretager en transformation af data, således at Løsningen herefter håndterer data på en normaliseret og standardiseret form. Baseret på den normaliserede form kan det samlede nyt datasæt beregnes, og dette lagres sammen med ændringer i Løsningen. Herefter kan et nyt sæt totaldata Det vil sige den samlede datamængde for hele dataområdet dannes og gøres tilgængeligt for udtræk. Sideløbende med at gøre det ny totaludtræk tilgængeligt, kan adviseringer overføres. Behov til hvordan ændringsadviseringer håndteres er beskrevet i use case B8. Følgende overordnede behov er tilknyttet use case A2. Behov.Høj.07. Hente ændringsudtræk fra CPR-registret (CPR) Løsningen kan hente et ændringsudtræk fra CPR-registret ved hjælp af sikker filoverførsel og kan kvittere for modtagelse. Behov.Høj.08. Validering af registerændringsudtræk Løsningen kan automatisk validere, at et registerændringsudtræk modtaget af Løsningen er korrekt overført, jf. use case B3. Behov.Høj.09. Indlæsning af registerændringsudtræk Løsningen kan indlæse et registerændringsudtræk fra CPR-registret som en fil i Løsningen, jf. use case B1. Behov.Høj.10. Transformering i forbindelse med modtagelse af registerændringsudtræk Løsningen kan transformere et registerændringsudtræk fra CPR-registret til en normaliseret form. Det gælder også eventuelle metadata modtaget i forbindelse med registerændringsudtrækket. Løsningen skal understøtte, at transformationen benytter tabeller og algoritmer, og at disse kan lagres i Løsningen. Behov.Høj.11. Beregn samlet totaludtræk Løsningen kan beregne et nyt totaludtræk på baggrund af registerændringsudtrækket og det nuværende totaludtræk. Behov.Høj.12. Advisering i forbindelse med modtagelse af registerændringsudtræk Løsningen kan automatisk generere adviseringsdokumenter om ændringer i totaludtræk og automatisk sende adviseringer til Anvendersystemet, hvis det abonnerer på ændringer, jf. use case B Use case A3: Overfør udtræk Løsningen skal understøtte overførsel af CPR-data fra Løsningens totaludtræk til Anvendersystemet. Dette kan både ske på Anvendersystemets egen opfordring, og som konsekvens af, at Anvendesystem er blevet adviseret om ændringer i totaludtrækket lagret i Løsningen. Det skal således være muligt for Anvendersystemet både at modtage samtlige CPR-data i Løsningen og en delmængde heraf, herunder ændringer i forhold til seneste overførsel af CPR-oplysninger fra Løsningen til Anvendersystemet. I denne use case skal Løsningen altså kunne håndtere en anmodning fra Anvendersystemet og på den baggrund på effektiv vis overføre data til Anvendersystemet. 21
22 Use case A3 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Overfør udtræk Anvendersystemet kan konfigurere og hente et nærmere specificeret udtræk fra Løsningens totaludtræk. Dagligt eller på nærmere specificeret tidspunkt Løsningen lagrer et komplet, aggregeret totaludtræk fra CPR-registret, jf. use case A1 og A2. Løsningen, Anvendersystemet 1. Anvendersystemet anmoder om et udtræk af data (se Behov.Høj.13). 2. Anmodningen indeholder eventuelt parametre (se Behov.Høj.16 og Behov.Høj.17). 3. Løsningen modtager anmodningen (se Behov.Høj.13). 4. Løsningen forbereder og overfører udtrækket til Anvendersystemet (se Behov.Høj.14 og Behov.Høj.15). Det ønskede udtræk er overført til Anvendersystemet. Følgende aktivitetsdiagram skitserer et muligt overordnet forløb i use case A3. Løsningen Anvendersystem Modtag anmodning Anmod om udtræk Klargør udtræk til forsendelse Log til afregning m.m. Send udtræk Modtag udtræk Håndter udtræk Figur 9 Use case A3: Modelskitse for overførsel af udtræk fra Løsningen til Anvendersystemet. Som vist på Figur 9 sender Anvendersystemet en anmodning om et udtræk til Løsningen. Løsningen modtager anmodningen om udtrækket og forbereder herefter udtrækket til forsendelse, inden det sendes til Anvendersystemet. Samtidig hermed logges informationer om adgangen til data, samt forbrugsinformationer til en eventuel afregning. Følgende overordnede behov er tilknyttet use case A3. 22
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 Anvendersystemet. Behov.Høj.14. Overførsel af udtræk Løsningen kan 1) automatisk overføre det udtræk, Anvendersystemet anmoder om, og 2) understøtte, at Anvendersystemet selv kan hente det udtræk, Løsningen har stillet til rådighed efter en anmodning om overførsel. Behov.Høj.15. Format for udtræk Løsningen understøtter, at udtræk kan foretages som flad, kommasepareret fil, samt i struktureret form ved den seneste version af OIO-XML. Behov.Høj.16. Udtræksparametre I forbindelse med overførsel af et udtræk fra Løsningen til Anvendersystemet tillader Løsningen, at Anvendersystemet på en let tilgængelig måde kan konfigurere udtræksparametre til at specificere, hvilke dele af udtrækket der skal udtrækkes og i hvilket format. Det er her særligt relevant at kunne udtrække data på baggrund af ændringsadvisering, jf. use case B8. Behov.Høj.17. Konfiguration af udtræksparametre Løsningen tillader, at Anvendersystemet kan konfigurere udtræksparametre således, at disse automatisk tages i betragtning, uden at disse eksplicit inkluderes i anmodningen. 4.4 Use case B1: Indlæsningsformater Det er centralt for registerudtræk fra CPR-registret, at Løsningen er i stand til at indlæse data fra registerudtrækket, samt behandle og lagre dem i en normaliseret repræsentation. Løsningen skal derfor være i stand til at indlæse data fra CPR-registret. Use case B1 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Indlæsningsformater Løsningen er i stand til at indlæse alle data ved registerudtræk og registerændringsudtræk fra CPR-registret. Dagligt eller på nærmere specificeret tidspunkt Data fra CPR-registret er tilgængelige for Løsningen, jf. use case A1 og A2. Løsningen Ved passende konfiguration af Løsningen kan data indlæses i Løsningen før videre behandling (se Behov.Høj.18, og Behov.Høj.19). Data er indlæst i Løsningen. Følgende overordnede behov er tilknyttet use case B1. Behov.Høj.18. Indlæsning af registerudtræk Løsningen kan indlæse registerudtræk fra CPR-registeret, jf. specifikationen 6. Behov.Høj.19. Indlæsning af registerændringsudtræk Løsningen kan indlæse registerændringsudtræk fra CPR-registeret 7. 6 Jf. u12180-p pnr nøgler off valgfrie recordtyper.pdf, tilgængelig fra siden 7 Jf. u12170-p ændringsudtræk off valgfrie recordtyper.pdf, tilgængelig fra siden 23
24 4.5 Use case B2: Udstil metadata Det er væsentligt, at informationer om data (metadata) udstilles på Løsningen. Som minimum udgøres metadata af information om dataaktualitet (hvor nye er data, hvornår er de sidst opdaterede), samt hvilken kilde der har leveret data. Metadata stilles til rådighed for Anvendersystemet gennem Løsningens udstillede grænseflader, jf. use case B6, samt i de udtræk, der leveres til Anvendersystemet, jf. use case A3. Use case B2 Udstil metadata sammen med data Formål Anvendersystemet kan hente metadata om de data, som det tilgår via Løsningen. Frekvens I forbindelse med modtagelse af registerudtræk og registerændringsudtræk fra CPR-registret. Startbetingelser At data indlæses fra CPR-registret, jf. use case A1 og A2. Aktører Løsningen Overordnet forløb 1. Løsningen modtager et registerudtræk eller et registerændringsudtræk, der inkluderer metadata (se Behov.Høj.20, Behov.Alm.01). 2. I forbindelse med modtagelsen dannes automatisk visse metadata (se Behov.Alm.04). 3. Ved udtræk af Anvendersystemet returneres relevante metadata, der er lagret sammen med udtræksdata (se Behov.Alm.02 og Behov.Alm.03). Slutbetingelser Metadata er sammen med data leveret til Anvendersystemet. Følgende overordnede behov er tilknyttet use casen. Behov.Høj.20. Metadata kan modtages i forbindelse med modtagelse af registerudtræk eller registerændringsudtræk Løsningen kan modtage metadata sammen med registerudtræk og registerudtræksdata, jf. use case A1 og A2. Behov.Alm.01. Metadata kan lagres i Løsningen Løsningen kan normalisere og lagre metadata, således at metadata kan tilbydes Anvendersystemet sammen med data til udtræk. Behov.Alm.02. Dataaktualitet indgår i udstillede services Løsningen understøtter, at informationer om aktualitet af data og kilde indgår i dens udstillede services. Behov.Alm.03. Dataaktualitet indgår i leverede data Løsningen understøtter, at informationer om aktualitet af data og kilde indgår i de data, der leveres til Anvendersystemet. Behov.Alm.04. Metadata dannes automatisk af Løsningen Løsningen danner automatisk visse metadata i forbindelse med håndtering af data, herunder tidsstempler for modtagelse af registerudtræk, og identifikation af datakilde. 4.6 Use case B3: Validering og sikring af datakvalitet Løsningen skal i forbindelse med modtagelse og håndtering af data sikre, at datakvaliteten er tilstrækkelig. Dette inkluderer validering af, at modtagelsen af registerudtræk og 24
25 registerændringsudtræk sker korrekt, at modtagne data er formateret korrekt, og at indholdet er korrekt. Use case B3 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Validering og sikring af datakvalitet Sikre, at de data, der indlæses i Løsningen, er af tilstrækkelig kvalitet. I forbindelse med modtagelse af registerudtræk og registerændringsudtræk fra CPR-registret. At data fra CPR-registret er overført, jf. use case A1 og A2. Løsningen 1. Løsningen kontrollerer, at det overførte registerudtræk eller registerændringsudtræk er overført helt. Det vil sige, at der ikke mangler data (se Behov.Høj.21, Behov.Høj.24 og Behov.Høj.25). 2. Løsningen kontrollerer, at registerudtrækket eller registerændringsudtrækket overholder formatspecifikationerne for CPR-data (se Behov.Høj.22, Behov.Høj.24 og Behov.Høj.25).. 3. Løsningen kontrollerer, at data i registerudtrækket eller registerændringsudtrækket overholder dataspecifikationerne for CPR-data (se Behov.Høj.23, Behov.Høj.24 og Behov.Høj.25).. Modtagne registerudtræk og registerændringsudtrækket er valideret og kan indlæses, jf. use case B1. Følgende overordnede behov er tilknyttet use case B3. Behov.Høj.21. Validering af dataoverførsel Løsningen understøtter specifikation og effektuering af en valideringsmekanisme, der kontrollerer, at et registerudtræk eller registerændringsudtræk, som hentes fra CPR-registret, er korrekt overført. Dette kan fx realiseres ved at anvende checksum eller kontrol af særlige markører (slutrecords) i data. Behov.Høj.22. Validering af dataformat Løsningen understøtter specifikation og effektuering af en valideringsmekanisme, der kontrollerer, at det specificerede dataformat for et registerudtræk eller registerændringsudtræk er overholdt. Dette kan fx realiseres ved at anvende viden om dataformatet til at kontrollere, at formatet er syntaktisk overholdt. Behov.Høj.23. Validering af dataindhold Løsningen understøtter specifikation og effektuering af en valideringsmekaniske, der kontrollerer, at modtagne data er indholdsmæssigt korrekte, herunder at en angivet dato faktisk er en korrekt dato (fx overholder antal dage i den pågældende måned). 25
26 Behov.Høj.24. Validering af CPR-formatet Løsningen kan validere, at dataformat er som specificeret 8 med hensyn til korrekt overførsel, format og dataindhold i forbindelse med modtagelse af registerudtræk og registerændringsudtræk fra CPR-registret. Behov.Høj.25. Håndtering af valideringsproblemer Løsningen understøtter konfiguration af, hvordan problemer i forbindelse med validering håndteres. I udgangspunktet skal Løsningen understøtte, at registerudtrækket eller registerændringsudtrækket ikke opfattes som korrekt overført, hvis valideringen fejler. 4.7 Use case B4: Udtræk af logningsinformation Løsningen skal kunne udtrække de informationer, der er logget af Løsningen. Løsningen foretager logning af adgang til data i forbindelse med fx opslag, udtræk, anmodninger, mv. for at sikre krav til sikkerhed. Løsningens logning skal være robust og i et format, der kan eksporteres. Behandling af informationerne foretages i et eksternt system. Use case B4 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Udtræk af logningsinformation At logningsinformation fra Løsningen kan gennemses og behandles i et eksternt system. Dagligt eller på nærmere specificeret tidspunkter Løsningen udstiller udtræk til Anvendersystemet, jf. use case A1, A2 og A3. Løsningen 1. Løsningen logger og lagrer opslag, modtagelse af registerudtræk og registerændringsudtræk, overførsel af udtræk, mv. (se Behov.Høj.26). 2. Løsningen genererer et udtræk af logningsinformationer, og gør udtrækket tilgængeligt for eksterne systemer (se Behov.Høj.27). Logningsudtræk kan inspiceres og indlæses i andre systemer hos Kunden. Følgende overordnede behov er tilknyttet use case B4. Behov.Høj.26. Datagrundlag for logning Løsningen skal logge alle relevante informationer om adgang til udstillede data, særligt med henblik på at sikre adgangslogning i forbindelse med krav til sikkerhed, og logning i forbindelse med Løsningens effektivitet. Behov.Høj.27. Udtræk af logningsinformationer Løsningen kan generere et udtræk af logningsinformationer fra Løsningen og stille det til rådighed for Anvendersystemet. Løsningen understøtter, at Anvendersystemet selv henter logningsinformationer, der er gjort tilgængelige via Løsningen. Logningsinformation skal være i gængse maskinlæsbare formater, fx som kommaseparerede fil. 8 Jf. u12180-p pnr nøgler off valgfrie recordtyper.pdf, tilgængelig fra siden og u12170-p ændringsudtræk off valgfrie recordtyper.pdf, tilgængelig fra siden 26
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 afregningen foretages i et eksternt system. Use case B5 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Udtræk af forbrugsinformation At forbrugsinformation fra Løsningen kan gennemses og behandles i et eksternt system med henblik på generering af afregning. Dagligt eller på nærmere specificeret tidspunkter Løsningen udstiller data til Anvendersystemer, jf. use case A3. Løsningen 1. Løsningen logger informationer om forbrug i forbindelse med alt ekstern anvendelse, som fx ved anmodning om udtræk fra Løsningen (se Behov.Alm.05). 2. Løsningen genererer et udtræk af forbrugsinformationer og gør udtrækket tilgængeligt for eksterne systemer (se Behov.Alm.06). Forbrugsudtræk kan inspiceres og indlæses i Anvendersystem. Følgende overordnede behov er tilknyttet use case B5. Behov.Alm.05. Forbrugsinformationer Løsningen skal logge forbrugsinformationer omkring anvendelse af udstillede data, der tillader afregning efter forbrug, herunder tidspunkt, Anvendersystem, type og volumen af data, der er tilgået og eventuelle tilmeldinger om ændringsadviseringer. Behov.Alm.06. Udtræk af forbrugsinformationer Løsningen kan indsamle information om forbrug af data fra Løsningen til Anvendersystemet og stille denne information til rådighed for Anvendersystemet som et udtræk. Løsningen understøtter, at Anvendersystemet selv henter de forbrugsinformationer, der er gjort tilgængelige via Løsningen. Forbrugsinformation skal være i gængse maskinlæsbare formater. 4.9 Use case B6: Administrer services Løsningen skal understøtte visning af en oversigt fx gennem en brugergrænseflade af de services, der på et givet tidspunkt er publiceret (udstillet) via Løsningen. Denne oversigt skal sikre, at nye services kan udstilles, redigeres eller fjernes fra samlingen af udstillede services. Løsningen kan desuden understøtte versionering, hvilket vil sige, at den samme service er udstillet i forskellige versioner. 27
28 Use case B6 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Administrer services At de services, der er udstillet på Løsningen, kan administreres. Dagligt eller på nærmere specificeret tidspunkter Der findes en administrationsgrænseflade, der tillader administration af services. Løsningen, Administrator 1. Administratoren kan administrere services, herunder oprette, vise, redigere og slette services (se Behov.Høj.28, Behov.Høj.29, Behov.Alm.07 og Behov.Alm.08). Administratoren har udført den ønskede inspektion eller administration af services i Løsningen. Følgende overordnede behov er tilknyttet use case B6. Behov.Høj.28. Administration af de services der udstilles på Løsningen Løsningen kan administrere de services, der udstilles på Løsningen, herunder tilføje nye, vise, redigere og slette services. Dette kan fx realiseres ved konfiguration af Løsningen. Behov.Høj.29. Publicering (udstilling) af services Løsningen kan publicere en service i et servicekatalog, og sikre at servicen herefter kan tilgås af Anvendersystemet. Dette kan fx realiseres ved konfiguration af Løsningen. Behov.Alm.07. Versionering af services Løsningen understøtter versionering af services. Det vil sige, at Løsningen tillader at services er tilgængelige i flere versioner samtidigt og kan tilgås af forskellige Anvendersystemer. Behov.Alm.08. Katalog over services Løsningen kan sammenstille et katalog over publicerede services, der kan gøres tilgængeligt for et Anvendersystem, forudsat at brugeren er Administrator Use case B7: Driftsovervågning Løsningen skal understøtte driftsovervågning af Løsningen, således at et driftsovervågningssystem løbende kan sikre, at Løsningen er operativ. Use case B7 Formål Frekvens Startbetingelser Aktører Overordnet forløb Slutbetingelser Driftsovervågning At det kan overvåges, at Løsningen fungerer efter hensigten og er operativ, samt at nedbrud af Løsningen kan opdages snarest muligt. Kontinuerligt. Løsningen, Driftsovervågning Driftsovervågningen er i stand til at forespørge Løsningen, om denne fungerer efter hensigten, idet Løsningen udstiller en grænseflade med dette formål (se Behov.Høj.30, Behov.Alm.09, og Behov.Alm.10). Driftsovervågningen er orienteret om, hvorvidt Løsningen 28
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, automatiseret monitoreringssystem at forespørge på aktuel driftsstatus. Behov.Alm.10. Udtræk af driftslog Løsningen kan understøtte udtræk af den information, der logges i forbindelse med drift, således at en driftsrapport kan udfærdiges Use case B8: Administrer og afsend ændringsadviseringer Løsningen skal afsende ændringsadviseringer til Anvendersystemet på baggrund af de ændringsadviseringer, som Anvendersystemet er tilmeldt. Det skal derfor være muligt for Anvendersystemet at tilføje, fjerne eller redigere tilmeldinger til ændringsadviseringer. Tilmeldinger kan have tilknyttede parametre, som fx frekvens for adviseringer. Use case B8 Administrer og afsend ændringsadviseringer Formål Understøtte Anvendersystemets administration og af tilmeldinger om ændringsadviseringer, og afsende ændringsadviseringer på baggrund af Anvendersystemets tilmeldinger til ændringsadviseringer. Frekvens Dagligt eller på nærmere specificeret tidspunkter Startbetingelser Administration af tilmeldinger til ændringsadviseringer er muligt. Løsningen er i stand til at generere ændringsadviseringer i forbindelse med relevante ændringer i totaludtrækket, jf. use case A1 og A2. Aktører Overordnet forløb Slutbetingelser Løsningen, Anvendersystemet 1. Det er muligt at administrere tilmeldinger til ændringsadviseringer og angive parametre i forbindelse med tilmeldingen (se Behov.Høj.31, Behov.Høj.32, Behov.Høj.33, og Behov.Høj.34). 2. Baseret på disse tilmeldinger foretager Løsningen ændringsadviseringer i forbindelse med ændringer i Løsningens totaludtræk (se Behov.Høj.31, Behov.Høj.36, Behov.Høj.37, Behov.Høj.38, og Behov.Alm.11). Et Anvendersystem er tilmeldt ønskede ændringsadviseringer, og Løsningen adviserer på baggrund af de ønskede tilmeldinger ved ændringer i totaludtrækket. Følgende overordnede behov er tilknyttet use case B8. 29
Informationsmøde vedrørende Proof of concept for en integrationsplatform
Informationsmøde vedrørende Proof of concept for en integrationsplatform Dagsorden 1. Velkomst 2. Selve Løsningen 3. Visionen 4. Datamodel 5. Milepæle og prøver 6. Open source 7. Praktisk information Selve
Læs mereKOMBIT A/S (herefter Kunden ) ønsker tilbud på et Proof of Concept til en fremtidig infrastruktur (herefter Løsningen ).
Annoncering af køb af et proof of concept til en fremtidig infrastruktur I medfør af lovbekendtgørelse nr. 1410 af 7. december 2007 om indhentning af tilbud på visse offentlige kontrakter (tilbudsloven)
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
25. april 2013 NOTAT Anvenderkrav til Støttesystemet Klassifikation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk
Læs mereServiceplatformen informationsmateriale. Leverandørmøde 7. februar 2013
Serviceplatformen informationsmateriale Leverandørmøde 7. februar 2013 1 Om Serviceplatformen Dette informationsmateriale beskriver kort Den fælleskommunale Serviceplatform: formålet med Serviceplatformen,
Læs mereLøsningsbeskrivelse. Den fælleskommunale Serviceplatform
Løsningsbeskrivelse Den fælleskommunale Serviceplatform Januar 2014 1 Indhold 2 Serviceplatformen... 2 3 Hjemmesiden www.serviceplatformen.dk... 3 3.1 Administrationsmodul... 4 3.2 Servicekatalog... 4
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
25. april 2013 Klik her for at angive tekst. NOTAT Bilag 14: Anvenderkrav til Støttesystemet Organisation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) kombit@kombit.dk CVR
Læs mereBilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer)
Klik her for at angive tekst. Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Krav og vejledning til
Læs mereVersion 1.0. Vejledning til brug af Støttesystemet Organisation
Version 1.0 Vejledning til brug af Støttesystemet Organisation kombit@kombit.dk CVR 19 43 50 75 Side 1/6 1. Indledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT indkøb af
Læs mereOIS - Applikationskatalog
OIS - Applikationskatalog OIS arkitekturprodukter 25. januar 2018 Indledning Dokumentationen omkring OIS er struktureret med inspiration fra OIO Arkitekturguidens arkitekturreol, således at arkitekturprodukterne
Læs mereVejledning til leverandørers brug af Serviceplatformen
Vejledning til leverandørers brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange...
Læs mereFordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014
Fordeling af journalnotater og dokumenter Udkast til løsningsmodel Marts 2014 1 Indledning Denne præsentation beskriver, på et overordnet plan, følgende områder i forhold til en fremtidig fordelingsmekanisme,
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
30. april 2013 NOTAT Bilag 12: Anvenderkrav til Støttesystemet Beskedfordeler (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334
Læs mereKlik her for at angive tekst.
30. april 2013 Klik her for at angive tekst. NOTAT Klik her for at angive tekst. Bilag 16: Anvenderkrav til Støttesystemet Ydelsesindeks version 1.0 (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav
Læs mereInformationsmateriale til kommunerne om Den fælleskommunale Serviceplatform
Informationsmateriale til kommunerne om Den fælleskommunale Serviceplatform Version 1.0, september 2013 Den fælleskommunale Serviceplatform Ved årsskiftet 2013/14 åbner Den fælleskommunale Serviceplatform
Læs mereBilag 2: Kravspecifikation - Side 1
Bilag 2: Kravspecifikation - Side 1 Use-Cases Syddjurs Kommune betragter den tværgående sundhedsplatform som en del af en større infrastruktur, hvor data flyder mellem forskellige elementer. Dette dokument
Læs mereUnderbilag 2Q Vilkår for integration til støttesystemet Klassifikation
Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation 1. Indledning og vejledning Nærværende vejledning beskriver, hvordan Anvendersystemer afsender og/eller modtager objekter til/fra
Læs mereVejledning til kommuners brug af Serviceplatformen
Vejledning til kommuners brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange på Serviceplatformen...
Læs mereBilag 2 - Fælles arkitekturramme for GD1-GD2-GD7. Etablering af datadistribution på den Fællesoffentlige Datafordeler
Bilag 2 - Fælles arkitekturramme for GD1-GD2-GD7 Etablering af datadistribution på den Fællesoffentlige Datafordeler Version: 0.8 Status: udkast Oprettet: 10.3.2014 Dato: 16. juni 2014 Dokument historie
Læs mereStrategi 2013-2017 Danmarks Miljøportal
Strategi 2013-2017 Danmarks Miljøportal Introduktion Danmarks Miljøportal (DMP) har ansvaret for en digital infrastruktur på miljøområdet, der gør det muligt for myndigheder og offentlighed at få nem adgang
Læs mereVilkår vedrørende brug af Støttesystemet Beskedfordeler
Vilkår vedrørende brug af Støttesystemet Beskedfordeler 1 Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer afsender og/eller modtager beskeder fra Støttesystemet Beskedfordeler,
Læs mereErfaringer med CPR-replikering
Erfaringer med CPR-replikering Dette dokument beskriver en række overvejelser vi har gjort os i forbindelse med at vi har udviklet en Proof of Concept (PoC) af en CPR-replikeringstjeneste for KOMBIT. CPRs
Læs mereN OT AT. Arbejdsgang i forbindelse med afsendelse af dokument til Dokumentboks. Overordnet vision til håndtering afsendelse af dokumenter
N OT AT Arbejdsgang i forbindelse med afsendelse af dokument til Dokumentboks Dette notat indeholder en beskrivelse af arbejdsgange til håndtering af afsendelse af dokumenter til Dokumentboksen eller måske
Læs mereFaktaark for Byg og Miljø
14. juni 2016 Faktaark for Byg og Miljø Overordnet beskrivelse og baggrund for Byg og Miljø Indholdsfortegnelse 1. Indledning... 2 2. Baggrund og formål... 3 Byg og Miljø består af tre dele... 3 Byg og
Læs mereKlik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks
23. maj 2013 HHK/KMJ NOTAT Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk
Læs mereInformationsmateriale til leverandørerne om. Den fælleskommunale Serviceplatform Version 1.1, december 2013
Informationsmateriale til leverandørerne om Den fælleskommunale Serviceplatform Version 1.1, december 2013 Den fælleskommunale Serviceplatform Fra 1.januar 2014 åbner den fælleskommunale Serviceplatform
Læs mere1. Release- og Versioneringsstrategi for Serviceplatformen og services
7. januar 2014. Serviceplatformen 1. Release- og Versioneringsstrategi for Serviceplatformen og services Nærværende notat beskriver Serviceplatformens Release- og Versioneringsstrategier. Formålet med
Læs mereIntroduktion til Støttesystem Ydelsesindeks
Introduktion til Støttesystem 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af hvilke komponenter,
Læs mereVejledning til leverandørers brug af Serviceplatformen
Vejledning til leverandørers brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange...
Læs mereIntegration SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans) Integrationsbeskrivelse - version 2.1.0
Integration SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans) Integrationsbeskrivelse - version 2.1.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer
Læs mereTil kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer
UdbudsVejledning Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog,
Læs mereEDI. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1. Copyright: Naddon version 201010
EDI Microsoft Dynamics NAV 2009 SP1 Klassisk Side 1 Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller i anden form - uden forudgående skriftlig tilladelse fra
Læs mereBilag 12. Drift af SUP-systemer. Udkast af 12. juni Udarbejdet for. SUP-Styregruppen
Kan med fordel udskrives på en farveprinter, idet figurerne er i farver. SUP-specifikation, version 2.0 Bilag 12 Drift af SUP-systemer Udkast af 12. juni 2003 Udarbejdet for SUP-Styregruppen Uddrag af
Læs mereKrav og vejledning til kommunernes fremtidige it-udbud
Klik her for at angive tekst. Krav og vejledning til kommunernes fremtidige it-udbud I forbindelse med det forestående monopolbrud udarbejder KOMBIT i samarbejde med kommunerne en trin-for-trin drejebog,
Læs mereIntroduktion til Klassifikation
Introduktion til Klassifikation 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Klassifikation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af
Læs mereDataadgang & Serviceplatform
Dataadgang & Serviceplatform Projektchef Mahdad Fahimi og Konsulent Michel Sassene Udfordringer ved adgang til data Data findes i forskellige formater og platforme og hos forskellige leverandører (specialiserede
Læs mereSAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA
26. marts 2014 NOTAT SAPAs forretningsmæssige behov i relation til Dialogintegration Dette notat beskriver SAPAs specifikke forretningsmæssige behov i forhold til integration med relevante ESDH-/fagsystemer,
Læs mere10. sept 2013 NOTAT. Integrationsmodel støttesystemer
10. sept 2013 NOTAT Integrationsmodel støttesystemer KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/13 1. Indledning... 3 2. Arkitekturens
Læs mereIntroduktion til Støttesystem Organisation
Introduktion til Støttesystem Organisation 1. Om dokumentet Dette dokument formidler et overblik over Støttesystemet Organisation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse
Læs mereBILAG 0 TIL KONTRAKT OM EOJ-SYSTEM DEFINITIONER
BILAG 0 TIL KONTRAKT OM EOJ-SYSTEM DEFINITIONER 1 INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved indgåelse heraf. Formål med bilag: Formålet
Læs mereVilkår for brug af Støttesystemet Sags- og Dokumentindeks
Version 1.0 Vilkår for brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og
Læs mereDECEMBER Vejledning til kommunens snitfladestrategi
DECEMBER 2016 Vejledning til kommunens snitfladestrategi Dette notat introducerer arbejdet med kommunens snitfladestrategi. Snitfladestrategien beskriver kommunens strategiske beslutninger vedr. snitflader
Læs mereIT-ARKITEKTURPRINCIPPER 2018
IT-ARKITEKTURPRINCIPPER 2018 5 It-arkitekturmål 5 Arkitekturprincipper Følg eller forklar Fælleskommunale arkitekturprincipper og -regler IT-ARKITEKTURMÅL Billigere it Sammenhængende it Mere robust og
Læs mere<navn på proces eller use case>
-- AKT 444548 -- BILAG 1 -- [ Bilag B1_Skabelon Integrationstabel ] -- Bilag B1 Integrationstabel Formålet med integrationstabellerne er at danne et samlet overblik over de tekniske integrationer, der
Læs mereIt-principper. Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune
It-principper Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune Indledning It-principperne er grundstenene for it-arkitekturen i Sønderborg Kommune. Principperne skal bidrage til, at vi
Læs mereBilag 1: Teknisk dialogmøde for udformningen af Digital Post
Bilag 1: Teknisk dialogmøde for udformningen af Digital Post Næste generation Digital Post, 2016 Indhold Indledning... 2 Kap. 1 Formelle rammer... 3 Kap. 2 Vision og formål... 3 Kap. 3 Næste generation
Læs mereSNITFLADER TIL INDEKSER. Præsentation af de fælleskommunale støttesystemernes snitflader til indekser
SNITFLADER TIL INDEKSER Præsentation af de fælleskommunale støttesystemernes snitflader til indekser Introduktion Fokus At give et overblik over: Integration til indekserne Forudsætninger for integration
Læs mereUNDERBILAG 3A.1 TIL KONTRAKT OM EOJ-SYSTEM. Use case Opfølgning
UNDERBILAG 3A.1 TIL KONTRAKT OM EOJ-SYSTEM Use case Opfølgning INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Rammeaftalen og vil blive fjernet ved indgåelse heraf. Formål med bilag:
Læs mereBilag 9, Kvalitetssikring
Bilag 9, Kvalitetssikring Version Ændringer Dato 2.1 Ændret i: 06-02-2014 - Punkt 1 - Punkt 2 - Krav 9.1 - Krav 9.2 - Krav 9.3 - Krav 9.5 - Krav 9.6 - Krav 9.7 - Krav 9.8 - Tilføjet krav 9.14 - Tilføjet
Læs mereScope dokument for Advisservice
18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.
Læs mereSF1460_A Modtag besked Integrationsbeskrivelse - version 2.3.0
SF1460_A Modtag besked - version 2.3.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.2.2
SF1460_C Aflever besked - version 2.2.2 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereIT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007
IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med
Læs mereIntegration SF1920 NemLogin / Digital fuldmagt Integrationsbeskrivelse - version 1.0.0
Integration Integrationsbeskrivelse - version 1.0.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-02-10 MVC 0.1 Første version 2015-03-04 ehe 0.3 Klargjort
Læs mereResumé NSI har udviklet en funktionel prototype med en visuel brugergrænseflade, der giver ikke-teknikere mulighed for at tilgå adviseringsservicen.
Fælles testmiljøer Statens Serum Institut Sektor for National Sundheds-it - Anvenderguide: Visuel adviseringsklient, en funktionel prototype Artillerivej 5 2300 København S Dato: 12.12.2013 Version: 1.0
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.4.0
SF1460_C Aflever besked - version 2.4.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereUnderbilag 14 C: Afprøvningsforskrifter til prøver og tests
Underbilag 14 C: Afprøvningsforskrifter til prøver tests Udbud om levering, installation, implementering, support, drift vedligehold af Borgeradministrativt System (BAS) Indhold underbilag 14 C Afprøvningsforskrifter
Læs mereTekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark
Tekniske krav til spiludbydere i forbindelse med opnåelse af tilladelse til at udbyde online spil i Danmark Version 1.10 Versionshistorik Version Dato Opsummerende beskrivelse af ændringer 1.00 2010-10-5
Læs mereUnderbilag 14 B: Oversigt over prøve- og testtyper. Udbud om levering, installation, implementering, support, drift og vedligehold af BAS
Underbilag 14 B: Oversigt over prøve- og testtyper Udbud om levering, installation, implementering, support, drift og vedligehold af BAS Indhold underbilag 14 B Oversigt over prøve- og testtyper 14 B Oversigt
Læs mereKlik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks
30. april 2013 NOTAT Klik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks Indhold: 1. Indledning og vejledning... 3 2. Krav vedr. Systemets anvendelse af Støttesystemet
Læs mereFLIS-projektets mål og prioritering
FLIS-projektets mål og prioritering Den 5. december 2018 fastlagde FLIS styregruppen 10 projektmål for FLIS-projektet. Målene bygger på FLIS strategien fra 2015, input fra FLIS følgegruppen og den løbende
Læs mereOverblik over egne sager og ydelser
1 Overblik over egne sager og ydelser Mathilde Illum Aastrøm, Digitaliseringsstyrelsen og Steen Andersen, OptimumIT September 2017 INITIATIVETS FORMÅL Nemmere at få klaret sine ærinder Servicen bliver
Læs mereSTS Designdokument. STS Designdokument
STS Designdokument i STS Designdokument STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik 1 2.1 Eksterne
Læs mereIntegration Generelle vilkår og forudsætninger Integrationsbeskrivelse - version 0.1
Integration Integrationsbeskrivelse - version 0.1 rnes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 201n-nn-nn xxx 0.1 Første version Referencer Ref Titel Kommentarer
Læs mereVejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer
3. september 2013 Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder
Læs mereBilag 4: Dokumentation
Bilag 4: Dokumentation Udbud af løn- og personalesystem Side 1 Indhold bilag 4 Bilag 4 Dokumentation... 3 4.1 Indledning... 3 4.2 Overordnede dokumentationskrav... 3 4.3 Dokumentation af leverance... 3
Læs mereInformationsmateriale til kommunerne om Den fælleskommunale Serviceplatform
Informationsmateriale til kommunerne om Den fælleskommunale Serviceplatform Version 1.1, januar 2014 Den fælleskommunale Serviceplatform Ved årsskiftet 2013/14 åbnede Den fælleskommunale Serviceplatform
Læs mereVejledning i at anvende åbningskvittering. Juli 2016
Vejledning i at anvende åbningskvittering Juli 2016 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du vil anvende åbningskvittering på materialer. Du skal have en af følgende roller
Læs mereDOKUMENTBROKER Koncept
DOKUMENTBROKER Koncept Copyright 2012 INDHOLDSFORTEGNELSE 1 Hvad er DokumentBrokeren?...1 1.1 Formål...1 1.2 Fordele...1 1.3 Baggrund...2 2 Komponenter...3 2.1 Dataflet...4 2.2 Platform og teknologi...4
Læs mereKravspecifikationen er udformet med vekslende tekstuel beskrivelse af behov og krav og de relevante behov og krav.
18. marts 2013 KMJ NOTAT SAPA Udbudsbilag Til brug for SAPA udbudsforretning udarbejdes følgende bilag: Bilag 0 Definitioner I dette bilag vil de definitioner som benyttes i kontrakten og på tværs af bilagene
Læs mereRettelsesblad/ Supplerende meddelelse nr. 16
Rettelsesblad/ Supplerende meddelelse nr. 16 Dato 21. december 2018 Sagsbehandler Per Krogsgaard Mail pkro@vd.dk Telefon 244 3359 Dokument 18/10743-9 Side 1/13 Til de bydende på Udbud af s IT-drift Herved
Læs mereUnderbilag 2O Beskedkuvert Version 2.0
Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...
Læs mereVejledning i at anvende besvarelsesformular. Juli 2016
Vejledning i at anvende besvarelsesformular Juli 2016 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du skal anvende besvarelsesformular på postkasser eller materialer. Du skal
Læs mereSmartFraming Et vindue til nationale sundhedssystemer. Version 3.0
SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med
Læs mereVejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer
Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder kommunerne i det
Læs mereBBR - Kontekstdiagram
BBR arkitekturprodukter 1. marts 2019 BBR - Kontekstdiagram Indledning Dokumentationen omkring BBR er struktureret med inspiration fra FDA arkitekturreolen, således at arkitekturprodukterne afspejler denne
Læs mereIntroduktion til Digital Post. Digitaliseringsstyrelsen August 2019
Introduktion til Digital Post Digitaliseringsstyrelsen August 2019 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital
Læs mereForretningsmæssigt leverandørspor - Serviceplatformen
Forretningsmæssigt leverandørspor - Serviceplatformen Dagsorden 1. Velkomst og ramme for dialogen 2. Forretningsmæssig ramme 3. Arbejdsgange 4. Services på Serviceplatformen 5. Forretningsmæssige muligheder
Læs mereBilag 3 - Løsningsbeskrivelse. over kravopfyldelse. Undervisningsministeriets udbud - Fremme af evalueringskulturen. 28. juni 2005
Uddannelsesudvalget L 101 - Bilag 3 Offentligt Bilag 3 - Løsningsbeskrivelse og oversigt over kravopfyldelse Undervisningsministeriets udbud - Fremme af evalueringskulturen i folkeskolen 28. juni 2005
Læs mereNemRolle. KOMBIT adgangsstyring med sikkerhed og overblik. Beskrivelse af funktioner og anvendelse
NemRolle KOMBIT adgangsstyring med sikkerhed og overblik Beskrivelse af funktioner og anvendelse NemRolle KOMBIT adgangsstyring med sikkerhed og overblik NemRolle er en samlet, komplet løsning til administration
Læs mereFolkekirkens It s arkitekturprincipper
Folkekirkens It s arkitekturprincipper Arkitekturprincipperne består af 11 principper, som skal anvendes ved alle nyanskaffelser og større ændringer af eksisterende it systemer. Arkitekturprincipperne
Læs mereDigital post Snitflader Bilag A2 - REST Register Version 6.3
Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER
Læs mereIT-arkitekturstyring i Syddjurs Kommune
IT-arkitekturstyring i Syddjurs Kommune Arkitekturprincipper 1. Skab sammenhængende digitale oplevelser for borgere og virksomheder 2. Forretningens behov skal drive og definere løsningerne 3. Understøt
Læs mereVejledning til udarbejdelse af jobfunktionsroller og tilknytning til brugersystemroller
Vejledning til udarbejdelse af jobfunktionsroller og tilknytning til brugersystemroller Indhold 1. Introduktion... 2 1.1 Baggrund... 2 2. Adgangsstyring for brugervendte systemer... 3 2.1 Brugervendte
Læs mereVejledning i at anvende besvarelsesformular. August 2019
Vejledning i at anvende besvarelsesformular August 2019 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du skal anvende besvarelsesformular på postkasser eller materialer. Du skal
Læs mereProcedurer for styring af softwarearkitektur og koordinering af udvikling
LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode
Læs mereIDAP manual Emission
IDAP manual Emission Dato: 08-06-2005 16:32:35 Indhold INDHOLD... 1 1 EMISSION... 2 1.1 KURVER... 2 1.2 RAPPORTER... 5 1.3 DATA REDIGERING... 6 1.3.1 Masse redigering... 7 1.3.2 Enkelt redigering... 10
Læs mereecpr erstatnings CPR Design og arkitektur
1 ecpr erstatnings CPR Design og arkitektur Indhold ecpr erstatnings CPR... 1 Indhold... 2 Formål... 3 Overblik... 4 Snitflader... 4 Komponenter... 5 Webservice... 5 Statuskomponent... 5 Forretningslag...
Læs mereFælles retningslinjer for REST webservices
Fælles retningslinjer for REST webservices Fællesoffentlig digital arkitektur Pelle Borgsten, Nikolaj Malkov, Christian Callsen Dagsorden Punkt 1. Formål 2. Principper og forretningsbehov 3. Retningslinjer
Læs mereSpm.2: Ordregiver bedes bekræfte at tilbuddet skal afleveres den og ikke som angivet i Bilag A den 31.8 kl. 10.
Senest opdateret d. 21.8.2015 Dokumentet indeholder alle til dato offentliggjort spørgsmål og svar. I tilfælde af, at Silkeborg Kommune finder det nødvendigt at foretage ændringer eller supplere oplysningerne
Læs mereIntroduktion til Støttesystem Sags- og Dokumentindeks
Introduktion til Støttesystem Sags- og Dokumentindeks 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Sags- og Dokumentindeks i den fælleskommunale infrastruktur. Formålet er
Læs mereKravspecification IdP løsning
Kravspecification IdP løsning Resume IT-Forsyningen, som varetager IT-drift for Ballerup, Egedal og Furesø Kommuner, ønsker at anskaffe en IdP/Føderationsserverløsning, der kan understøtte en række forretningsmæssige
Læs mereADK 1.0 KRAVSPECIFIKATION
ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 23-06-2014 MST Oprettelse af integrationskrav 0.2 25-06-2014 HAH Review for forståelighed og stringens.
Læs mereDen Digitale Landevej - Arkitekturprodukt
Indhold 1 A1 Målbillede af arkitekturen... 2 2 Målbilledet... 2 3 Kort om komponenterne... 4 3.1 Sikkerhed... 4 3.2 Opfølgning... 4 3.3 Service udstilling... 4 3.4 Logistik og bestilling... 4 3.5 Stamkort...
Læs mereMinikonference om Sag og Dokumentstandarder 15. juni 2011, Odense
CPR Broker version 2.0 Minikonference om Sag og Dokumentstandarder 15. juni 2011, Odense Steen Deth, Chefarkitekt sde@gentofte.dk CPR data hvor svært (og interessant) kan det være? Kommune Borgerservice
Læs mere23. maj 2013Klik her for at angive tekst. HHK/KMJ. Vejledning til brug af Støttesystemet Adgangsstyring
23. maj 2013Klik her for at angive tekst. HHK/KMJ Vejledning til brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående
Læs mereStøttesystemerne. Det er tid til
1 Det er tid til Støttesystemerne 2 Kombit Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, hvor bedre borgerservice med færre ressourcer er i centrum. Kommunernes mål er at bevare
Læs mereDKAL Snitflader REST Register
DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4
Læs mereBilag 10. Afprøvning
Bilag 10 Afprøvning 2 Vejledning til tilbudsgiver Dette bilag beskriver, hvordan Leverancer og videreudviklingsydelser skal afprøves af Kunden i samarbejde med Leverandøren. Bilaget gælder kun for større
Læs mereKontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet
Kontrakt om Videreudvikling, Vedligeholdelse og Support af IMK2- systemet Bilag 1 Definitioner 12.05.2016 Version 1.0 [Vejledning til tilbudsgiver: Bilaget er i sin helhed at betragte som et mindstekrav
Læs mereGuide til integration med NemLog-in / Signering
Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere
Læs mere