Bilag 3A.1 Kravliste Version

Transkript

1 Bilag 3A.1 Kravliste Version

2 Vejledning til Tilbudsgiver Dette bilag består af tre faneblade: 1) "Funktionelle krav" indeholdende de funktionelle krav til et. 2) "Non-funktionelle krav" indeholdende de non-funktionelle krav til et og øvrige non-funktionelle krav til Leverandøren. 3) "Krav til Ydelserne" indeholdende driftskravene til Leverandøren efter Overtagelsesdagen. De tre faneblade indeholder hver især en række krav, som alle er prioriteret i henhold til det nedenstående, hvilket Tilbudsgiver skal være opmærksom på: Kravtype Beskrivelse Vægtning af krav Mindstekrav ( MK ) angiver krav, som er ufravigelige og skal opfyldes fuldt ud af Tilbudsgiver. Mindstekrav indgår ikke i evalueringen Mindstekrav Tilbudsgiver kan således ikke i sit tilbud tage forbehold for opfyldelse af et mindstekrav, og feltet Opfyldt i bilag 3A.1 (Kravliste) skal være markeret med X. I modsat fald er tilbuddet ikke-konditionsmæssigt med den konsekvens, at ATP i henhold til gældende lovgivning er forpligtet til at forkaste tilbuddet uden yderligere vurdering. Bemærk, at mindstekrav ikke indgår i tilbudsvurderingen, og at ATP dermed ikke evaluerer på opfyldelsesmåden. K0-krav K0-krav er de få essentielle krav, som er afgørende for ATP at få, og hvor ATP ønsker at evaluere på opfyldelsesmåden. K0 krav vægter højest -krav -krav er alle de krav, som er vigtige for ATP at få, og hvor ATP ønsker at evaluere på krav vægter mindre end K0 opfyldelsesmåden. krav K2-krav K2-krav er alle de krav, som ATP gerne vil have, og hvor ATP ønsker at evaluere på K2 krav vægter mindre end opfyldelsesmåden. krav For alle krav i de tre faneblade skal Tilbudsgiver ved afkrydsning i kolonnen "" tilkendegive opfyldelsesgraden af kravene. Hvis kravet er markeret som, og uddybende besvarelse desuden efterspørges, så benyttes feltet Beskrivelse/reference til at indsætte en henvisning til det konkrete punkt i Løsningsbeskrivelsen (bilag 3B), hvor den uddybende beskrivelse af det tilbudte skal fremgå, herunder en beskrivelse af hvordan kravet bliver løst i Hvis kravet besvares med markering i, benyttes feltet Beskrivelse/reference til at indsætte en henvisning til det konkrete punkt i Løsningsbeskrivelsen (bilag 3B), hvor der fremgår en uddybende beskrivelse af, på hvilke punkter den tilbudte løsning afviger fra ATP s krav. Hvis kravet besvares med markering i, kan feltet Beskrivelse/reference benyttes til at uddybe, hvorfor kravet ikke opfyldes. Har Tilbudsgiver ikke angivet en værdi for kravopfyldelsesgrad, da vil kravet få opfyldelsesgraden. Dette er ikke gældende for mindstekrav. Har Tilbudsgiver angivet mere end en værdi for kravopfyldelsesgrad eller for løsningsmåde, vil kun den markering der forekommer i kolonnen længst til venstre blive taget i betragtning. De funktionelle krav og visse af de non-funktionelle krav (undtagen mindstekrav) kan opfyldes på forskellige vis,, eller Via udvikling. Løsningsmåden angives ved afkrydsning i kolonnen "Løsningsmåde" i overensstemmelse med nedenstående: Vejledning til Tilbudsgiver Bilag 03A.1 - Kravliste.xlsx Side 2 / 66

3 Løsningsmåde Beskrivelse Vægtning af løsningsmåder betyder at et out-of-the-box indeholder eksisterende og allerede afprøvet Løsning via standard vægter funktionalitet, der understøtter ATP s krav. højest Eksempler på standard er: At et out-of-the-box indeholder alle de parametre og opsætninger, der skal til, for at understøtte ATP s krav efter at data er konverteret ind i et. Dette kan være tilfældet når et f.eks. indeholder funktionalitet, workflows eller standardrapporter, der matcher ATP s krav. betyder, at et bringes til at understøtte ATP s krav ved tilpasning af allerede eksisterende funktionalitet via konfiguration og parameteropsætning. Løsning via tilpasning vægter mindre end løsning via standard Eksempler på tilpasning er: Opsætning af grunddata Opsætning af workflows Tilføjelse af et nyt felt på et skærmbillede (ændring af brugergrænsefladen) Tilføjelse af nye elementer/data til en allerede eksisterende standardrapport betyder, at et kan bringes til at understøtte ATP s krav ved at tilføje ny funktionalitet eller ved at ændre eksisterende funktionalitet via ændringer i kildekoden eller tilføjelser til kildekoden. Eksempler på udvikling er: Udvikling af ny funktionalitet Udvikling af en ny standardrapport eller kundespecifik rapport Udvikling af brugergrænseflader Udvikling af integrationer Løsning via udvikling vægter mindre end løsning via tilpasning Vejledning til Tilbudsgiver Bilag 03A.1 - Kravliste.xlsx Side 3 / 66

4 Funktionelle krav Leverandørens besvarelse Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_1 Opgaveindbakke Indhold af Opgaveindbakke et skal understøtte visning af opgaver genereret fra: * komponenten Validering * komponenten Hændelser * komponenten Kontrol * komponenten (Gen)beregning af ydelser * fejl i udsendelse af automatiske beskedskabeloner * overvågning på udgående beskeder. * journalisering af post på sager foretaget af Posthåndteringsleverandøren (indscannede dokumenter) FUN_2 K0 Opgaveindbakke * lt Vis Opgave tt d f t t f K d åd i et skal understøtte, at en via en opgave i Opgaveindbakken og ved et enkelt klik, kan få åbnet og præsenteret den sag eller part som opgaven omhandler via det Tværgående overblik. FUN_3 OpgaveIndbakke Vis opgavedetaljer et skal understøtte, at en kan vælge at få vist alle detaljer for en opgave. Opgavedetaljerne inkluderer information (jf. informationsmodel familieydelse): * CPR-nr for den person som opgaven omhandler * Arbejdspakkenavn, Opgaveprioritet, Opgavestatus, Opgaveforfaldsdatoen, Opgavetitel, Opgavebeskrivelse, Oprettelsesdato, OprettetAf (, et), ReserveretAf(), OpgavebehandletAf (KundeRådgiver). Rolle, Løsningsmåde Vejledning FUN_4 FUN_5 K2 Opgaveindbakke Opgaveindbakke Vis arbejdspakke med tilknyttede opgaver et skal understøtte, at en eller Driftleder kan filtrere på arbejdspakker, og dermed få vist indholdet (de enkelte opgaver), samt hvilke opgaver der allerede er igang (reserveret). Opgaveindbakken skal bl.a. kunne indeholde information [jf. informationsmodel familieydelse]: * Arbejdspakkenavn, Opgaveprioritet, Opgavestatus, Opgaveforfaldsdatoen, Opgavetitel Sortering og filtrering af opgaver et skal understøtte, at en eller Driftleder kan foretage en stigende/faldende/alfabetisk sortering af opgaver i opgavelisten ud fra de tilgængelige informationer., driftleder, driftleder FUN_6 Opgaveindbakke Vælg (reservér) opgave et skal understøtte, at en kan reservere en eller flere opgaver i Opgaveindbakken. Når en reserverer en opgave, skal et blokere for at andre e kan reservere opgaven og opgaven skal fremgå som reserveret i Opgaveindbakken. FUN_7 Opgaveindbakke Frigiv en opgave et skal understøtte, at en kan frigive en opgave som de har reserveret, så den bliver tilgængelig for andre e. FUN_8 Opgaveindbakke Frigiv en opgave et skal understøtte at alle reserverede opgaver frigives på et fast defineret tidspunkt (1 gang om dagen). FUN_9 K2 Opgaveindbakke Frigiv en opgave et skal understøtte, at en Driftsleder kan frigive en opgave eller flere opgaver som tilhører e i Driftlederens Sektion, så opgaverne bliver tilgængelige for andre e. Driftleder Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 4 / 66

5 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_10 Opgaveindbakke Fremsøge opgaver et skal understøtte, at en kan fremsøge opgaver i en given arbejdspakke. FUN_11 K2 Opgaveindbakke Seneste fem søgninger et skal understøtte, at en får præsenteret de seneste 5 fremsøgte arbejdspakker først. FUN_12 Opgaveindbakke Visning af arbejdspakker et skal understøtte, at en Driftleder kan få et samlet overblik over arbejdspakker. Overblikket skal ud for hver arbejdspakke indeholde antal opgaver i henholdvis prioriteret høj, mellem og lav. Overblikket skal kunne vises i listeform og grafisk form. FUN_13 Opgaveindbakke Eksporter opgaveoversigt et skal understøtte, at en eller Driftleder kan eksportere en fremsøgt opgaveliste med de oplysninger, som er fremkommet i søgningen til et standard filformat så som Microsoft Excel, CSV. FUN_14 Opgaveindbakke Prioritér opgaver et skal understøtte, at en forretningsadministrator kan ændre opgaveprioritering for en eller flere opgaver, uden at skulle åbne hver opgave, hver gang en prioriteringsværdi skal ændres. FUN_15 Opgaveindbakke Administrer rettigheder og opgavetyper et skal understøtte, at en kan angive hvilke opgavetyper som skal vises for hvilken type af brugere. Det kan være bestemte opgavetyper, som skal præsenteres for bestemte jf roller i ift. CRUD matrix. FUN_16 K0 Sagshåndtering Informationer på sager et skal understøtte, at en kan udføre sagsbehandling. Sagerne skal indeholde de informationer, der fremgår af informationsmodel Sag og informationsmodel Familieydelse. FUN_17 K0 Sagshåndtering Vis og redigér information på sag et skal understøtte at en kunderådgiver kan få vist og redigere i alle informationer jf. bilag 3A.8 (Oversigter), fane Informationsbehandling_gui på sagen. FUN_18 FUN_19 Sagshåndtering Sagshåndtering Oversigt over beskeder på sagen et skal understøtte, at en på en sag kan se en oversigt over ind- og udgående beskeder knyttet til sagen og kan sorteres efter: * datorækkefølge * om beskeden er ind eller udgående * dokumenttype (jf informationsmodellen) Historik på sagsinformationer et skal understøtte, at en kan se historikken på de enkelte attributter på en sag. Af historikken skal fremgå: * beslutningsgrundlaget for ændringerne * reglerne og versionen, der var gældende ved ændringerne. * Identifikation af kunderådgiveren eller systemet som har foretaget ændringen Rolle, driftleder Driftleder, driftleder Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 5 / 66

6 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_20 Sagshåndtering Opret/ændre sag et skal understøtte, at en kan oprette og ændre en sag jf. bilag 3A. 8 (Oversigter), fane Informationsbehandling_gui. et skal stemple de enkelte informationer med en identifikation af, hvem der har foretaget ændringen og hvornår. FUN_21 Sagshåndtering Når sag ændres et skal på baggrund af ændringer foretaget af kunderådgiver: * markere på sagen årsagen til ændringen (f.eks genberegning, omgørelse af validering, ændring i indkomstoplysninger) * validere ens input ud fra de relevante regler for validering * beregne eller genberegne ydelsen på baggrund af ens input * opdatere hvilke perioder, der udbetales ydelser * efter manuel indberetning skal sagen fortsætte i det automatiske flow med markering af, at den efterfølgende automatiske behandling ikke igen giver udfald til manuel behandling med samme årsag, som udløste den opgave, som netop har behandlet. Rolle Vejledning FUN_22 FUN_23 Sagshåndtering Sagshåndtering Angiv søgekriterier et skal understøtte, at en kan definere en søgning på sager, dokumenter og journalnotater ud fra de informationer som er indeholdt på sagen. Informationerne skal kunne kombineres i søgningen og der skal være mulighed for at angive kriterier på de enkelte informationer såsom: * Større end, > * Mindre end, < * I mængden, IN * Ikke i mængden, NOT IN * Tekstoperatoren LIKE * Forskellig fra, <> * Søgning I t på ll tværs ll af sager f k d t er skal understøtte, at det er muligt at finde/søge relevante sager ud fra indholdsmæssige kriterier. Fx navn, afsender, tema, dato for brev indgået, brevdato o.lign., til brug for aktindsigt efter forvaltningsloven, offentlighedsloven og persondataloven og til brug for intern udsøgning. FUN_24 Sagshåndtering Vis søgeresultat (sager) Søgeresultatet skal udmøntes i en oversigt over sager. Oversigten skal indeholde minimum følgende oplysninger: * Sagsoverskrift * CPR nr * KLE nr * Sagstilstand * Kassationskode FUN_25 MK Sagshåndtering * Sagsbehandler Vis adressebeskyttelse et skal synligt for en kunderådgiver i brugergrænsefladen til et, markere om et CPR nr. er omfattet af navne- og adressebeskyttelse i CPR. Dette er et mindstekrav, som er ufravigeligt og skal opfyldes fuldt ud af Tilbudsgiver. Tilbudsgiver kan således ikke i sit tilbud tage forbehold for opfyldelse af et mindstekrav, og feltet Opfyldt skal være markeret med X. I modsat fald er tilbuddet ikkekonditionsmæssigt med den konsekvens, at ATP i henhold til gældende lovgivning er forpligtet til at forkaste tilbuddet uden yderligere vurdering. Bemærk, at mindstekrav ikke indgår i tilbudsvurderingen, og at ATP dermed ikke evaluerer på opfyldelsesmåden. Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 6 / 66

7 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_26 Sagshåndtering Visning af skærmede sager et skal for sager og dokumenter med begrænset adgang synligt markere på sagen eller dokumentet, at det indeholder begrænset adgang, samt initialerne på vedkommende der har tilført sagen eller dokumentet en begrænset adgang. FUN_27 K0 Sagshåndtering Åbn sag et skal understøtte, at en gennem et klik på en sag fra sagsoversigten får åbnet sagen i et sagshåndterings skærmbillede. FUN_28 Sagshåndtering Slettemarkering et skal understøtte, at en kan påføre en sag en slettemarkering, så den ikke vises i sagsoversigten eller ved en fremsøgning af en sag. Rolle Vejledning FUN_29 Sagshåndtering Udskriv sagsakter et skal understøtte, at en kan udskrive sagsakterne for en sag (f.eks dokumenter og journalnotater). FUN_30 Sagshåndtering Søg og vis dokumenter et skal understøtte, at en skal kunne foretage en søgning på dokumenter i et. Søgeresultatet skal udmøntes i en dokumentoversigt, som minimum skal indeholde følgende oplysninger: * Dokumentnavn * Skabelonnummer * Dokumenttype * Dokumentstatus (f.eks slettemarkeret) * CPR nr * KLE nr * Dato FUN_31 K0 Sagshåndtering * Åbn K dokument d åd i (d id t h di t i d k t t) et skal understøtte, at en gennem et klik på dokumentet fra dokumentoversigten, får vist det valgte dokument. FUN_32 K2 Sagshåndtering Importér dokument et skal understøtte, at en kan importere et dokument fra en filstruktur til en sag i et. FUN_33 Sagshåndtering Flyt og kopiér dokumenter et skal understøtte, at en kan flytte samt kopiere et eksisterende dokument fra en sag/part til en anden sag/part. FUN_34 Sagshåndtering Slettemarkering af dokument et skal understøtte, at en kan påføre et dokument en slettemarkering, så det ikke fremgår af sagen. FUN_35 Sagshåndtering Opret journalnotat et skal understøtte, at en fra en given sag kan oprette i et journalnotat hvor følgende informationer fremgår: * Overskrift (prædefineret liste) * Tekstindhold (prædefineret og fritekst) * Sags id * Dato for oprettelse * Oprettet af (entydig identifikation af den der opretter dokument) Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 7 / 66

8 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_36 FUN_37 Sagshåndtering Sagshåndtering Søg og vis journalnotater et skal understøtte, at en skal kunne foretage en søgning på journalnotater i et. Resultatet af søgningen skal som minimum indeholde følgende oplysninger: * Journaloverskrift * Dato * Sagsbehandler * Sags ID * Tekstbeskrivelse Åbn journalnotat et skal understøtte, at en gennem et klik på journalnotatet fra søgningen, får vist det valgte journalnotat. FUN_38 K2 Sagshåndtering Flyt og kopier journalnotat et skal understøtte, at en kan flytte eller kopiere et eksisterende journalnotat fra en sag til en anden sag. FUN_39 Sagshåndtering Vis sagshistorik Sagshistorikken bestående af hændelseslog og journalnotater skal være synlige for. FUN_40 Sagshåndtering Opret ny opgave et skal understøtte, at en kan oprette en ny opgave. FUN_41 FUN_42 K2 Sagshåndtering Sagshåndtering Vis/ændre opgave et skal understøtte, at en kan få vist og ændre informationerne registreret på en opgave. Det skal herefter fremgå af opgaven: * hvad er blevet opdateret - det skal fremgå hvad før og efter værdier/tekst er * OpgavebehandletAf, fx, et mv. * hvornår der er foretaget en ændring - dato for ændring Eksporter søgeresultat et skal understøtte at en kan eksportere et søgeresultat (opgaver, sager, dokumenter og journalnotater), til et filformat såsom Microsoft Excel, CSV. FUN_43 K2 Sagshåndtering Print søgeresultat et skal understøtte at en kan printe et søgeresultat (opgaver, sager, dokumenter og journalnotater). FUN_44 Manuelle Breve Vælg afsendelseskanal et skal understøtte, at en i forbindelse med afsendelse af en besked, kan påføre om den skal afsendes som fysisk post. FUN_45 Manuelle Breve Vis beskedskabelon et skal understøtte at en Kunderågiver får vist de tilgængelige beskedskabeloner. Rolle Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 8 / 66

9 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_46 FUN_47 Manuelle Breve Manuelle Breve Vælg beskedskabelon et skal understøtte, at en kan vælge en beskedskabelon, og at denne som udgangspunkt indeholder: * en dato for hvornår beskeden er oprettet * hvem der har oprettet beskeden * tekstindholdet på beskeden * markering af at beskeden er udgående * eventuelle vedhæftninger (bilag blanketter etc ) Udfyld beskedskabelon (skriv brev) et skal understøtte, at en i forbindelse med arbejdet med en beskedskabelon, kan rette i de informationer som automatisk påsættes (flettes), samt tilføje en tekstuel beskrivelse på det sted i skabelonen, hvor der er mulighed for tekstredigering. Den færdige besked (med indflettet information) skal præsenteres for kunderådgiveren FUN_48 K2 Manuelle Breve umiddelbart efter at skabelonen er præudfyldt Gem kladde et skal understøtte, at en kan gemme et ufærdigt brev, og at det automatisk tildeles et versionsnummer. FUN_49 K2 Manuelle Breve Versionshistorik på kladder for udgående dokumenter et skal understøtte, at en kan fremfinde tidligere versioner af dokumenter (kladder) og få dem vist i den form og indhold, som gjorde sig gældende ved det aktuelle versionsnummer. FUN_50 Manuelle Breve Ændre kladde for udgående dokumenter, et skal understøtte, at en kan ændre i en kladde for udgående dokumenter samt i de informationer, der er tilknyttet dokumentet (jf informationsmodel Sag, klasse Dokument). et skal stemple dokumentet med identifikation af, hvem der har foretaget ændringen, hvornår den er foretaget og give dokumentet et nyt FUN_51 Manuelle Breve versionsnummer Underskriv besked et skal understøtte, at når en afsender en besked vedrørende en afgørelse, påføres beskeden automatisk ens navn som underskriver. Rolle Vejledning FUN_52 Manuelle Breve Igangsætte en masseudsendelse et skal understøtte, at en, kan igangsætte en masseudsendelse af beskeder til den Fællesoffentlige Printløsning, ud fra følgende: Dato for afsendelsen, modtager og beskedskabelon. FUN_53 K0 Tværgående Overblik Vis informationer i Tværgående overblik et skal kunne vise alle informationer jf. bilag 3A.8 (Oversigter), fane Informationsbehandling_gui i et Tværgående overblik. Leverandøren skal i samarbejde med ATP i afklaringsfasen bestemme hvilke informationer der vises. FUN_54 Tværgående Overblik Søg person et skal understøtte at en kan fremsøge en persons oplysninger via et opslag på fx: * CPR nr * Personnavn FUN_55 Tværgående Overblik * Personadresse (dansk og udenlandsk) Udvidet søgning et skal understøtte, at en kan taste dele af et: * CPR nr * Personadresse (dansk og udenlandsk) * Personnavn i det Tværgående Overblik og herefter blive præsenteret for en oversigt med max 20 valgmuligheder pr. side for pågældende søgekriterie. Det skal være muligt at vælge de enkelte søgeresultater og her fra få vist den konkrete sag, som personen er part i eller har en familieydelsesrelevant relation til Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 9 / 66

10 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_56 K0 Tværgående Overblik Vis alle informationer på en sag et skal understøtte, at en gennem et klik skal kunne få vist alle informationer på part/sag jf. bilag 3A.8 (Oversigter), fane informationsbehandling_gui. Rolle Vejledning FUN_57 Tværgående Overblik Vis hyperlink til eksterne sites et skal understøtte, at en fra det Tværgående Overblik kan aktivere link til websider/andre portalbaserede systemer og ad den vej åbne fx Schultz lovgivning eller Udbetaling Danmarks Vidensløsning. FUN_58 Tværgående Overblik Vis dokumenter og journalnotat i Tværgående Overblik et skal understøtte visning af de fem seneste dokumenter og journalnotater på sagen i det Tværgående overblik. Dokumenter og journalnotater skal kunne åbnes direkte herfra med et enkelt klik. FUN_59 Tværgående Overblik Vis informationer fra sags-, dokument- og ydelsesindeks i Tværgående Overblik et skal understøtte visning af informationer fra sags- og dokumentindeks samt ydelsesindeks. FUN_60 K0 administration Generel konfiguration af systemopsætning et skal understøtte, at en skal kunne konfigurere al information som udstilles i brugergrænseflader, skabeloner og genvejstaster: * beskedskabeloner * journalnotatskabeloner * arbejdspakker * opgaver * ydelsestyper * tekster på brugergrænseflader * tekster til hændelseslog * værdisæt på udvalgte attributter * kontoplan FUN_61 administration * Brugergrænseflade i ll til konfiguration f i ll Der skal være en brugergrænseflade til generel konfiguration af systemopsætning. Brugergrænsefladen skal kunne anvendes af en på superbrugerniveau. FUN_62 administration Konfiguration af FYYdelsesType et skal understøtte at en skal kunne oprette og ændre FYYdelsesTyper jf. Informationsmodel Familieydelse. FUN_63 administration Konfiguration af manuelle bevillinger et skal understøtte at en skal kunne konfigurere regler gældende for manuelle bevillinger (Roller, FYYdelsestyper og øvrige informationer på sagen). FUN_64 administration Konfigurer hyperlink til eksterne sites et skal understøtte, at en kan konfigurere hvilke hyperlinks, der skal vises for en. De links der fremgår af brugergrænsefladen skal kunne styres ud fra de informationer, der er på sagen. Fx link til specifik artikel i Instruks/Vidensløsningen (ATP løsning). Med konfiguration menes både oprette og ændre. /Su perbruger Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 10 / 66

11 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_65 K0 administration Versionering Alle konfigurerbare systemværdier skal versioneres og føres med dobbelthistorik, derudover skal det klart fremgå hvem og hvornår rettelsen er foretaget. Se krav til grundlæggende funktionalitet vedrørende dobbelthistorik. FUN_66 FUN_67 K0 administration administration Opret / ændre beskedskabelon et skal understøtte, at en kan oprette en skabelon samt redigere i en eksisterende: * navn på skabelon * skabelonnummer (bogstaver og tal) [skal autogenereres af systemet] * metadata tilknyttet dokumentet [jf Informationsmodel Sag - Class Dokument] * tekstuel beskrivelse samt logoopsætning etc. * flettefelter hvor et skal indsætte oplysninger fra parten på sagen og ind i skabelonen * regler for hvornår i det automatiserede flow skabelonen skal afsendes * angivelse af A, B eller C post (fysisk forsendelse) * Erindringsmarkering, indikere at systemet skal danne en erindring efter afsendelse af bvis kbeskedskabelon d et skal understøtte, at alle beskedskabeloner vises i et samlet overblik for en Forretningsadminstrator, med en tydelig markering af, hvornår en skabelon er en manuel beskedskabelon eller en automatisk beskedskabelon. FUN_68 administration Opret/ændre journalnotat skabelon et skal understøtte, at en kan oprette en ny skabelon samt ændre i en eksisterende: * navn på skabelon * skabelonnummer (bogstaver og tal) [skal autogenereres af systemet] * metadata fx KLE-nr tilknyttet journalnotatet [jf Informationsmodel Sag - Class Journalnotatskabelon] * tekstuel beskrivelse. * flettefelter hvor et skal indsætte oplysninger fra parten på sagen og ind i skabelonen Rolle Vejledning Sletning af skabelon sker ved at der indføres en ny version med tilhørende gyldig fra/til dato. FUN_69 administration Fremsøgning af tidligere versioner af skabeloner et skal understøtte, at en kan fremsøge tidligere versioner af besked- og journalnotatskabeloner. FUN_70 administration Ophørsdato for skabeloner et skal understøtte, at en kan sætte ophørsdato på eksisterende besked- og journalnotatskabeloner FUN_71 administration Design af skabeloner et skal understøtte skabeloner til design af beskeder og journalnotater. (layout). FUN_72 administration Formatering og præsentation af beskedindhold et skal understøtte, at tekster der indsættes i beskedskabeloner bliver vist korrekt i PDF. Teksten skal kunne indeholde, tal, billeder (logoer etc.) bogstaver og forskellige tegn såsom punktum, parentes, komma, kolon, dots, bindestreg og bogstaver fra udenlandske alfabeter. Teksten skal kunne redigeres i font størrelse, farve, og fremhævelse samt font navn Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 11 / 66

12 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_73 administration Versionering af beskedskabelon et skal understøtte, at kan foretage ændringer i en version af en beskedskabelon samtidig med, at den gældende version er i brug i driften. Rolle FUN_74 administration Opret/ændre sagstype og dokumenttype et skal understøtte, at en kan oprette nye: * Sagstyper (bruges til klassifikation af sager) * Dokumenttyper (bruges til klassifikation af dokumenter) samt ændre i de eksisterende sags og dokumenttyper. FUN_75 administration Opret/ændre værdisæt et skal understøtte, at en kan tilføje nye værdier (udvide udfaldsrummet) for på de attributter som ne eller et kan påføre en sag, et dokument, en opgave eller et journalnotat jf. Informationsmodel Familieydelser. FUN_76 FUN_77 administration administration Opret/ændre arbejdspakkeindhold et skal understøtte, at en kan oprette en ny arbejdspakke eller ændre i en eksisterende ved at angive hvilke opgaver, der tilhører en arbejdspakke. Opgaver skal kunne grupperes som en samling af: * OpgaveoprettetAf, fx, et, Posthåndteringsleverandøren * Dokumenttyper, klassificering af indholdet af beskeden. * Opgaveårsag, fx adresseændring, uklar samlivsstatus etc. * Samling KLE-numre. * En kombination af ovenstående * Tekster og overskrifter Opret/ændre arbejdspakkeindhold et skal understøtte, at opsætningen af arbejdspakker kan ske ved anvendelse af gængse operatorer som fx * Større end, > * Mindre end, < * I mængden, IN * Ikke i mængden, NOT IN * Tekstoperatoren LIKE FUN_78 K2 administration * Forskellig fra <> Konfigurer informationer i brugergrænsefladen et skal understøtte, at en kan administrere hvilke forretningsmæssige attributter fra informationsmodellerne jf informationsmodel Familieydelse der vises i ets brugergrænseflade. FUN_79 administration Ændre tekster på brugergrænseflade et skal understøtte, at en kan rette i hjælpetekster (mouse over på felter etc.) og beskrivende tekstblokke (permanente områder med vejledende tekst). FUN_80 administration Ændre systembeskeder incl. fejlbeskeder et skal understøtte, at en kan ændre i teksten i de systembeskeder et eventuelt sender i forbindelse med modtagelse af en indberetning eller ansøgning. FUN_81 administration Konfiguration af Selvbetjeningsløsning et skal understøtte, at en kan oprette nye eller redigere i eksisterende felter til indtastning af oplysninger (jf informationsmodel Familieydelse, som udstilles på Selvbetjeningsløsningen). Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 12 / 66

13 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_82 K2 administration Aktivering og deaktivering af brugertilfredshedsundersøgelser et skal understøtte, at en har mulighed for at aktivere og deaktivere brugertilfredshedsundersøgelser leveret af ATP s Øvrige Leverandører i Selvbetjeningsløsningen. FUN_83 K2 administration Modtag advis fra KOMBIT's Beskedfordeler et skal understøtte konfiguration af adviseringer fra KOMBIT's Beskedfordeleren, som systemet skal agere på. En advis skal kunne generere en opgave i opgaveindbakken eller igangsætte en automatisk proces, ved at der dannes en hændelse fx beregning af ydelse. FUN_84 K2 administration Send advis til KOMBIT's Beskedfordeler og opdater indeks Når der ændres på en sag, skal et afsende en advisering via KOMBIT's Beskedfordeler. Forinden skal Sags- og Dokumentindeks og Ydelsesindeks opdateres. Rolle Vejledning FUN_85 administration Konfigurer kommunikationskanal et skal understøtte, at en kan konfigurere hvilke kanaler (Fjernprint eller Sikkerpost) som benyttes til tværgående kommunikation mellem Udbetaling Danmark og de enkelte kommuner. FUN_86 Regeladministration Brugergrænseflade til konfiguration Der skal være en brugergrænseflade til konfiguration af regler og parametre. FUN_87 K0 Regeladministration Konfiguration af regler et skal understøtte, at en kan tilføje og ændre regler, som anvendes i et. Regler skal versioneres, så der altid forefindes en gældende version og eventuelt tidligere anvendt version. Ændringer i regler skal altid medføre en ny version af reglen. FUN_88 K0 Regeladministration Konfiguration af beregningsparametre et skal understøtte, at en har adgang til at tilføje og ændre i, alle de parametre der anvendes i beregningen, så som: * Grænseværdier (Fx Bundfradrag, BørneUngeReguleringssats) * Satser Parametre skal versioneres så der altid forefindes en gældende version og eventuelt tidligere anvendt version. Ændringer i parametre skal altid medføre en ny version. FUN_89 Regeladministration Dobbelthistorik på regler og parametre et skal understøtte, at en kan konfigurere en gyldig fra og gyldig til dato samt virkning fra og virkning til for samtlige regler og parametre. FUN_90 Regeladministration Konfiguration af historiske regler og parametre et skal understøtte at ændringer til regler og parametre kan virke bagudrettet, så eksisterende kørsler på beregninger, afgørelser etc. kan genkøres gennem en manuel initiering af en. FUN_91 Regeladministration Vis regelhistorik skal kunne se alle regler, hvornår de gælder fra og til samt hvornår de har virkning fra og til. Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 13 / 66

14 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_92 K2 Regeladministration Konfiguration af valideringsregler et skal understøtte, at en kan konfigurere valideringsregler. FUN_93 Validering Genvalider indberetning et skal understøtte, at en skal kunne gen-validere på eksisterende sager. Fx i forbindelse med ændring i valideringsregler tilbage i tid. Rolle FUN_94 K2 Validering Konfiguration af systembeskeder et skal understøtte, at en skal kunne koble systembeskeder til de valideringsregler som Selvbetjeningsløsningen benytter. beskederne skal aktiveres og vises på Selvbetjeningsløsningen når et finder fejl i forbindelse med validering af indtastede oplysninger. FUN_95 Validering Overstyring af systemvalidering et skal understøtte, at en kan i forbindelse med manuel behandling af en sag godkende eller omgøre resultatet af en validering og markere i sagen, at valideringen er udført manuelt, så samme validering ikke foretage igen, når sagen returneres tilbage til det automatiserede flow. Regler for hvilke systemvalideringer, der kan manuelt overstyres, skal opsættes i forbindelse FUN_96 Validering med afklaringsfasen Valider indberetning et skal ud fra et sæt af valideringsregler kunne validere de indkommende oplysninger/hændelser som modtages fra Selvbetjeningsløsningen, interne/eksterne registre eller i forbindelse med at der foretages ændringer til data af en. FUN_97 Validering Udfør validering Ved løbende validering af indtastede oplysninger på Selvbetjeningsløsningen eller i brugergrænsefladen for, skal et foretage valideringer så tidligt som muligt i processen. FUN_98 FUN_99 K0 Beskedhåndtering Beskedhåndtering Opret automatisk besked et skal kunne oprette en besked, som en del af et automatisk flow. Beskeden skal indeholde: * en dato for hvornår beskeden er oprettet * hvem der har oprettet beskeden * tekstindholdet på beskeden * markering af at beskeden er udgående * eventuelle vedhæftninger (bilag blanketter etc ) Underskriv besked et skal understøtte, at når der automatisk udsendes en besked vedr. en afgørelse, påføres beskeden automatisk ens navn som underskriver, hvis kunderådgiveren forinden har truffet afgørelse på sagen. Dette gælder også hvis en har afgjort enkelte oplysninger fx samlivsstatus, og et efterfølgende træffer afgørelse om berettigelse og ydelsers størrelser. Det gælder ikke når en ydelse FUN_100 K2 Beskedhåndtering tilkendes alene af et i det automatiske flow Fravælg automatisk udsendelse af besked (spærring på automatiske breve), manuelt, et skal understøtte, at en manuelt kan fravælge at automatisk genererede beskeder udsendes til borgeren, samt at det kan ske som følge af en eller flere hændelser defineret i reglerne. FUN_101 Beskedhåndtering Automatisk masseudsendelse et skal i en automatisk kørsel igangsætte en masseudsendelse af beskeder til den Fællesoffentlige Printløsning. Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 14 / 66

15 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_102 K0 Dan Udbetaling Udbetaling til danske og udenlandske konti Der skal kunne udbetales til danske og udenlandske konti via NemKonto. FUN_103 Dan Udbetaling Oprettelse af kontonummer i forbindelse med udbetaling til borger/myndighed Der skal i et kunne oprettes et kontonummer i det tilfælde, hvor det ikke er muligt at anvende NemKonto (ved fiktivt cpr nr). FUN_104 K2 Dan Udbetaling Udbetaling til danske og udenlandske konti med kontonr Der skal kunne opsættes en udbetalingskørsel af udbetalinger med kontonumre, som sendes direkte som konto til konto overførsel. FUN_105 Dan Udbetaling Igangsæt genudbetaling et skal understøtte, at en Leverandør på anmodning fra ATP på et vilkårligt tidspunkt kan igangsætte en genudbetaling af en udbetalingskørsel på udvalgte personer eller myndigheder eller på hele bestanden. FUN_106 Dan Udbetaling Manuel udbetaling - godkendelse et skal understøtte, at en kan danne en udbetaling manuelt og at en mauelt dannet udbetaling indgår i et særligt godkendelsesflows (ekstra kontrol). FUN_107 Dan Udbetaling Straksudbetalinger Straksudbetalinger skal kunne gennemføres direkte fra et, så udbetalingen gøres klar af kunderådgiveren og tages med i næste udbetalingskørsel (næste nat). FUN_108 Dan Udbetaling Stop udbetaling et skal understøtte at en kunderådgiver kan sætte en persons udbetalinger på hold, så udbetalingen ikke tages med, når der sendes til NemKonto. FUN_109 Økonomi Overfør bogføringsdata et skal med baggrund i en systemkørsel fastsat med en bestemt tidsfrekvens, kunne afsende bogførings- og afstemningsposter til ATP's økonomisystem, sådan at gældende regnskabslovgivning bliver overholdt. FUN_110 Dan Udbetaling Sum af udbetalingsposter til kommuner et skal kunne summere de beregnede udbetalingsposter til én udbetaling til en kommune, hvis der er flere sager under samme SE nr (fx anbragte børn). Hvis en udbetaling er en summeret udbetaling til en kommune skal ID'et gælde for den, men kunderådgiveren skal kunne se, hvilke personer udbetalingen vedrører. FUN_111 Dan Udbetaling Specifikation af sumudbetalinger et skal kunne danne en specifikation for summerede udbetalinger indeholdende CPR nr og ydelsestype. Rapporten skal kunne sendes via sags- og dokumentindeks til kommunen. FUN_112 Dan Udbetaling Sum af udbetalingsposter til Personer et skal kunne summere de beregnede udbetalingsposter til samme modtager for hver FYYdelsesType, således at modtager får en udbetaling pr. FYYdelsesType uanset antallet af børn. FUN_113 K0 Dan Udbetaling UdbetalingsID et skal generere et entydigt id for hver udbetaling. FUN_114 Dan Udbetaling Kontonumre til afstemning et skal påsætte ydelsesspecifikke kontonumre på udbetaling/afstemningsposterne. Kontonumrene skal være konfigurerbare af en. Kontoplanen leveres af ATP. Rolle Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 15 / 66

16 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_115 Dan udbetaling Referencetekst til afsender og modtager skal være sporbar Udbetalinger skal indeholde en unik reference som skal kunne slås op, og ses af en, i udbetalingssystemet på tværs af ydelser. Tekst til modtager skal godkendes af ATP. FUN_116 Modregning Modregningsordning et skal kunne modtage og indlæse en modregningsordning modtaget fra Debitor. FUN_117 K0 Modregning Modregning i udbetaling et skal ud fra en modregningsordning modtaget fra Debitor kunne modregne i en udbetaling, når udbetalingens forfaldsdato er nået. FUN_118 Modregning Kvittering for modregning et skal give besked til Debitor, når modregningen er sket. Beskeden skal indeholde information om den modregning der er foretaget (beløb, forfald mv.) FUN_119 Modregning Bogføring af modregning et skal først bogføre modregnet gæld, når udbetalingens forfaldsdato er nået. Rolle Vejledning FUN_120 K0 Kontrol Konfiguration af kontrolregler et skal understøtte, at en kan oprette og rette i parametre i kontrolregler til styring af forretningsmæssig funktionalitet. FUN_121 Kontrol Udfør Kontrol et skal understøtte, at en skal kunne igangsætte en kontrol på en udvalgt sagsmængde med en valgt regel. Sagsmængden skal kunne defineres ud fra værdier på sagernes informationer og kombinationer deraf jf. Informationsmodel Familieydelser. Fx sager med bevilget Børnetilskud eller sager med Statsborgerskab <> DK. FUN_122 Kontrol Overstyring af kontrol et skal understøtte, at en i forbindelse med manuel behandling af en sag kan godkende eller omgøre resultatet af den automatiske kontrol og markere i sagen at kontrollen er udført manuelt, så samme kontrol ikke foretages igen, når sagen returneres tilbage til det automatiserede flow. FUN_123 Kontrol Besked ved overstyring af kontrol et skal understøtte, at en kan opsætte pop-up beskeder når en i forbindelse med manuel behandling af en sag omgører resultatet af den automatiske kontrol. FUN_124 K0 Kontrol Bestem behov for manuel Kontrol et skal kunne kontrollere indkommende oplysninger, jf Informationsmodel Familieydelser, fra personer, myndigheder og registre ud fra opsatte regler implementeret i et. Hvis reglerne bestemmer det, skal der oprettes en Opgave til Opgaveindbakken om at manuel kontrol skal udføres af en. Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 16 / 66

17 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_125 Kontrol Kontroller dobbeltudbetalinger et skal understøtte at en kan opsætte regler i forbindelse med udbetalinger, således at en udbetaling på det samme beløb indenfor en tidsperiode (konfigurerbart) til den samme modtager stoppes. FUN_126 K0 Kontrol Kontrol af kritiske kørsler et skal understøtte automatisk kontrol af kritiske kørsler, fx i forbindelse med udbetalinger. Hvis der opstår en fejl i de kritiske kørsler skal der automatisk og med det sammen oprettes en prioritet 1 fejlsag og ATP skal underrettes. Rolle FUN_127 FUN_128 K2 K2 Kontrol Beregning af ydelser Stikprøvekontroller et skal understøtte udtræk af stikprøvekontroller. Stikprøverne skal kunne udtages på baggrund af kriterier, der defineres fra værdier på sagers informationer. Der skal kunne angives hvor mange stikprøver der skal udtages eller en procentvis angivelse af alle sager, der opfylder kriterierne. Fx skal der kunne udtages 5 % af alle sager hvor Samlivsstatus er Enlig Straksberegning et skal understøtte, at når en ændrer i oplysninger på en sag, kan de igangsætte en beregning om berettigelse til ydelser og ydelsernes størrelser på en sag. Resultatet af beregningen skal præsenteres for kunderådgiveren umiddelbart efter igangsættelsen. Hvis beregningen ikke viser det som var forventet, skal ne FUN_129 K2 Beregning af ydelser kunne gå tilbage til det oprindelige Afgør berettigelse til ydelse et skal understøtte, at en kan foretage en vurdering af om personen er berettiget til at modtage familieydelser og indtaste resultater herom, herunder markere i sagen, at personen er berettiget. et skal efterfølgende følge den manuelt indtastede afgørelse og se bort fra regler i et, som går imod den beslutning en har FUN_130 K2 Beregning af ydelser truffet Afgørelse om undtagelse af en regel I forbindelse med at en afgør at en Person er berettiget til en ydelse, skal det være muligt for en at markere at Personen er undtaget fra bestemte regler, fx indtægtsreguleringen. FUN_131 Beregning af ydelser Beregn beløbsstørrelser et skal foretage beregninger af ydelsers beløbsstørrelse på baggrund af sagens grundlag, regler, satser og grænseværdier, der er gældende for de enkelte ydelsestyper. FUN_132 Beregning af ydelser Beregning på ændret grundlag tilbage i tid et skal kunne udføre en beregning om berettigelse og ydelsesstørrelser på grundlag tilbage i tid, hvis det ændres. Fx i tilfælde af, at en persons Samlivsstatus ændres fra enlig til samlevende fra dags dato og 10 mdr. tilbage i tid. FUN_133 Persondata Indlæs og gem informationer et skal ved modtagelse af informationer fra Beriget Grunddata og andre interne eller eksterne dataleverandører kunne indlæse og gemme data. FUN_134 Sager & Dokumenter Låsning af sager et skal for hver gang der åbnes en eksisterende sag låse sagen og tilhørende dokumenter for redigering af andre brugere. et skal vise (gennem initialer på brugeren), hvem der er i gang med at redigere i sagen eller dokumentet. Visningen skal være synlig for kunderådgiverne. FUN_135 Sager & Dokumenter Frigiv sager og dokumenter automatisk et skal én gang hver nat, genåbne sager og tilhørende dokumenter, der stadig måtte være låst for redigering. Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 17 / 66

18 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_136 Sager & Dokumenter Frigiv sager og dokumenter automatisk ved afslutning et skal når en afslutter behandling af en sag frigive sagen, så den kan redigeres af andre. FUN_137 Sager & Dokumenter Tilføj hændelseslog et skal ved afslutning af behandling af en hændelse generere en hændelseslog på sagen indeholdende: *dato for oprettelse *årsag til stempling *beskrivende tekst FUN_138 Sager & Dokumenter * Initialer på kunderådgiver Tilføj jounalnotat automatisk et skal ved ændringer på sager generere et journalnotat indeholdende: * dato for oprettelse * årsag til ændring * beskrivende tekst FUN_139 K2 Sager & Dokumenter * ændret af Konfiguration af automatiske hændelseslog, journalnotater et skal understøtte, at en kan foretage ændringer til indholdet af den beskrivende tekst, som genereres i forbindelse med en journalnotatstempling, der indgår som et led i en automatiseret proces. FUN_140 Modtagelse af post Modtag Dokument med tilhørende metadata et skal modtage og indlæse dokumenter fra Posthåndteringsleverandøren mhp. at foretage en automatisk journalisering. FUN_141 K2 Modtagelse af post Match indgående post med udsendt et skal, for alle modtagne dokumenter fra Posthåndteringsleverandøren, foretage et opslag på ets sager og foretage en sammenstilling af den indgående posts entydige identifikation (en QR kode el. lign.) med de sager som findes i et og herefter journalisere posten på sagen. FUN_142 Modtagelse af post Opret sag ved modtagelse af dokument et skal, i de tilfælde hvor dokumentet ikke automatisk kan journaliseres, fordi der ikke findes en sag, oprette en ny sag og journalisere posten på denne. FUN_143 Modtagelse af post Opret opgave ved modtagelse af dokument et skal, oprette en opgave til Opgaveindbakken, når der er indkommende dokumenter fra Posthåndteringsleverandøren. En opgave kan indeholde følgende informationer (jf. informationsmodel Familieydelse) for opgave : * Oprettelsesdato * Prioritering af opgaven * Opgavebeskrivelse [tekstbeskrivelse genereret ud fra metadatainformationer på posten] * Hvem der har oprettet opgaven * Hvilke arbejdspakke opgaven tilhører * Tilknyttet KLE nr. * Hvornår skal opgaven seneste være afsluttet [forfaldsdato] * Opgavestatus, fx oprettet, afventer dokumentation, igang, udskudt, afsluttet * Opgaveårsag, fx ansøgning om Børnebidrag. Leverandøren skal i afklaringsfasen sammen med ATP fastlægge det endelige datasæt. Rolle Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 18 / 66

19 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_144 K2 Modtagelse af post Manuel omjournalisering et skal understøtte at en kan sende besked tilbage til Posthåndteringsleverandøren med en kort tekstbeskrivelse tilknyttet. Beskrivelsen skal indeholde oplysninger om hvilket andet ydelsesområde posten også ønskes jounaliseret til. FUN_145 K2 Modtagelse af post Håndter omjournalisering et skal understøtte at en kan sende forkert journaliseret dokumenter tilbage til Posthåndteringsleverandøren med en kort tekstbeskrivelse tilknyttet. Beskrivelsen skal indeholde oplysninger om årsag til returnering og evt. forslag til andet ydelsesområde, hvor Posthåndteringsleverandøren skal journalisere posten. FUN_146 Selvbetjening Print og gem som PDF fra selvbetjeningsløsning Selvbetjeningsløsningen skal give en person mulighed for at printe og gemme en ansøgning og/eller ændringer til egen sag som PDF. FUN_147 K0 Selvbetjening Borgerrettet funktionalitet Leverandøren skal levere en selvbetjeningsløsning, der skal udstille den borgerrettede funktionalitet, som er afspejlet i løsningsflows og aktivitetsbeskrivelserne. Informationerne som henholdsvis vises, indberettes og ændres fremgår af bilag 3A.8 (Oversigter), fane Informationsbehandling_gui. FUN_148 K2 Selvbetjening login som Person Selvbetjeningsløsningen skal understøtte brug af digital fuldmagt således, at en kunderådgiver kan logge på på vejne af en Person. FUN_149 Selvbetjening Digitale fuldmagter Selvbetjeningsløsningen og et skal understøtte brug af digital fuldmagt. FUN_150 K2 Selvbetjening Vedhæfte filer via Selvbetjeningen Det skal være muligt at vedhæftet standard dokumenter(microsoft doc, docx, pdf, txt etc.) af en størelse op til 10 mb. Rolle Person Person Person Vejledning FUN_151 Selvbetjening Kvittering til person Selvbetjeningsløsningen skal vise en kvittering til Person, hvor af det fremgår hvilke informationer, der er indberettet samt en konfigurerbar tekst om fx personens oplysningspligt, forventet sagsbehandlingstid mv. Kvitteringen afsendes efterfølgende til personen via Digital Post. FUN_152 Selvbetjening Journaliser kvittering Selvbetjeningsløsningen skal sikre at kvitteringen inkl. samtykkeerklæring mv. journaliseres i et. FUN_153 Selvbetjening Hårde valideringer Selvbetjeningsløsningen skal understøtte, at en Person kan gennemføre en ansøgning og afgive ændringer uden at blive stoppet af hårde valideringer dvs. Personen i sidste ende kan sende en ufuldstændig ansøgning. Dog skal Personen undervejs gøres opmærksom på mangler i ansøgningen og betydningen for fx sagsbehandlingtid. Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 19 / 66

20 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_154 K2 Selvbetjening Brugertilfredshedsundersøgelser i Selvbetjeningsløsningen Selvbetjeningsløsningen skal understøtte at brugertilfredshedsundersøgelser leveret af ATP's Øvrige Leverandører skal igangsættes så snart brugeren kommer ind på Selvbetjeningsløsningen, f.eks. i en lightbox. FUN_155 Sikkerhed Brugertilfredshedsundersøgelsen skal herefter kunne minimeres eller lignende, således at brugeren uhindret kan anvende Selvbetjeningsløsningen. Når brugeren er færdig med anvendelsen af Selvbetjeningsløsningen og lukker denne, skal brugertilfredshedsundersøgelsen automatisk maksimeres eller lignende, således at brugeren kan besvare undersøgelsen Vedligehold brugerrettigheder et skal benytte sig af en rollebaseret model for adgangsstyring, hvor brugere autoriseres på baggrund af deres tildelte rolle. et skal hertil understøtte, at der i et defineres og vedligeholdes roller/rettighedsgrupper som styrer adgangen til de forskellige dele af systemet, herunder adgangen til at udføre forskellige operationer (fx oprettelse, læsning, opdatering og sletning) på forskellige dataelementer. Rolle Person, Vejledning FUN_156 Sikkerhed Tildeling af rettigheder og adgang på brugerniveau et skal understøtte at en forretningsadministrator kan bestille rettigheder til en bruger ved angivelse af hvilke(n) rolle(r) brugeren skal have., forretningsadministrator FUN_157 Sikkerhed Adgang til vedligehold af brugerrettigheder og adgange Alle brugere, såvel forretningsmæssige som tekniske (privilegerede brugere) af systemet skal kunne oprettes og vedligeholdes af ATP. Leverandøren skal levere egen CRUDmatrice for de tekniske brugere. ATP IT sikkerhed FUN_158 Sikkerhed Log på et skal for ATP's interne brugere understøtte Single Sign-On med brugerens Windowslogin. FUN_159 Sikkerhed Skærmede/VIP sager et skal understøtte, at der kan opsættes begrænsninger på særlige sager, således at kun e med særlige adgange skal kunne behandle disse sager., FUN_160 Sikkerhed Mapning af systemroller Leverandøren skal i samarbejde med ATP specificere forretningsrollernes adgang til informationer på klasse- og attributniveau og mappe dem til systemroller jf. bilag 3A.8 (Oversigter), fane Forretningsroller. FUN_161 FUN_162 K0 Rapporter Rapporter Konfiguration og visning af rapporter et skal understøtte, at en forretningsadminstrator via en brugergrænseflade kan ændre informationer i definerede rapporter jf. bilag 3A.6a/Generisk udtræk service Snitfladebeskrivelse. Det skal være muligt for forretningsadministratoren at danne et prøveudtræk. Adgangen og konfiguration til og af rapporter skal være rollebaseret Driftlederrapportering et skal understøtte driftlederrapportering, hvor en Driftleder eller kan vælge rapporter, såsom: * Opgaver med overskredet deadline * Opgaver med deadline inden for et defineret tidsinterval * Opgaver i arbejdspakker fx fordelt på proritet Data skal være aktuelle (realtid), driftleder Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 20 / 66

21 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_163 K2 Regeladministration What if analyse et skal understøtte, at ATP skal kunne simulere ændringer i regler og satser. FUN_164 FUN_165 Rapporter Jobafvikling Kontrol af manuelle handlinger i forbindelse med svig et skal understøtte udtræk af lister over alle manuelle oprettelser, ændringer, sletninger af krav og udbetalinger. Listerne skal indeholde oplysninger om: * hvad der er lavet af udvalgte manuelle handlinger * hvem der har foretaget den manuelle handling * hvilken periode handlingen er foretaget i Listerne skal kunne genereres af en forretningsadministrator eller sættes op til automatisk generering og leveres til en modtager som en CSV fil Automatiserede kørsler et skal understøtte automatiserede kørsler. Rolle Vejledning FUN_166 K2 Jobafvikling Udstil jobafviklingsplan et skal understøtte at en kan se tidspunkter for planlagte automatiserede kørsler. FUN_167 Økonomi Bogføringsdato til ATP s økonomisystem et skal registrere en bogføringsdato, og denne skal føres med over i økonomisystemet. Med bogføringsdato forstås den dato, der bestemmer hvilken måned/regnskabsår bilaget medtages i regnskabet. FUN_168 FUN_169 K2 Økonomi Bogføringsperioder, der kan åbnes/spærres Der skal være 12 bogføringsperioder pr. regnskabsår tilgængelige i et, og det skal være muligt at åbne og lukke bogføringsperioderne. Bogføringsperioderne i et, der afleverer regnskabsdata til ATP ERP skal åbnes/lukkes på samme tidspunkt som i ATP ERP. Åbning og lukning varetages af ATPs Økonomiafdeling. Rettelser tilbage i tid bogføres med dags dato, dette skal også gælde fx afklaringslister, således at der kan trækkes låste lister med gamle skæringsdatoer Udstil liste/rapport et skal understøtte at kan danne en liste/rapport Økonomi indeholdende afholdte og/eller forventede udgifter og indtægter. Med forventede udgifter menes udbetalinger der endnu ikke er kommet til udbetaling. Det skal være muligt selv af definere perioden. FUN_170 K2 Tilbagesøgte udbetalinger - rapport Økonomi Det skal være muligt at udtrække specifikation af tilbagesøgte udbetalinger med årsagsforklaring, uanset at tilbagesøgning bliver håndteret via modregning. FUN_171 FUN_172 Økonomi Økonomi Konteringsdata skal være ydelsesspecifik et skal understøtte at Økonomisystemet modtager sumposter pr ydelsestype og denne skal kunne føres tilbage til posterne på CPR nr niveau i et. Kontering skal afspejle ydelsestype uanset at der sker summering af den enkelte personudbetaling. Periodisering Der skal ske periodisering i forhold til regnskabsperioder. Betaling vedrørende indeværende og tidligere perioder bogføres i indeværende regnskabsperiode, og forudbetalinger bogføres i kommende regnskabsperiode. Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 21 / 66

22 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_173 Svar fra banken skal danne bogføring i et Økonomi Kvitteringssvar fra banken skal anvendes til at danne bogføring, således at den faktiske betalingsstrøm registreres. Returnerede betalinger skal automatisk modtages i et og danne returbogføring. FUN_174 Økonomi Konfiguration af kontoplan Der er behov for at ATP løbende kan vedligeholde kontomapningen mellem et og Økonomisystemet. FUN_175 Afstemning Udfør intern grænsefladekontrol et skal generere en intern grænsefladekontrol mellem hver afsendelse og efterfølgende modtagelse af en ikke pengebærende transaktion internt i et. Det kunne fx være antal generede manuelle breve i forhold til det antal som er afsendt fra et. FUN_176 Afstemning Udfør intern grænsefladekontrol et skal som et led i den interne grænsefladekontrol, dokumentere pr dataelement, de steder hvor der er differencer mellem de ikke pengebærende transaktioner og hvad størrelsen på differencen er. FUN_177 K0 Afstemning Grænsefladekontrol Det er leverandørens ansvar at sikre, at hvor der afleveres data mellem et og andre systemer - jf. system context overblikket over grænseflader - skal alle dataoverførsler kontrolleres for, at de er korrekt overført og indlæst. fx i form af kontrol af headerinformation om sumfelter, antal, fil-løbenummer etc. Leverandøren skal gennemgå disse kontroller med ATP afstemningsgruppen i afklaringsfasen. Grænsefladekontrollen skal afholdes ved hver dataoverførsel og skal logges. Loggen skal fremvises til ATP på forlangende og skal udleveres i digitalt format, så den kan bruges i analysearbejde. I tilfælde af fejl ved overførsel af data over grænseflader skal ATP adviseres straks med relevant information, og fx skal et som et led i den interne grænsefladekontrol dokumentere pr dataelement, de steder hvor der er differencer mellem transaktioner og hvad størrelsen på differencen er. FUN_178 K0 Afstemning Dataleverancer til månedlige, kvartalsvise og årlige afstemninger af pengestrømme ATP har behov for at lave periodevise afstemninger til Økonomifunktionen, revisionen og lign. Til dette formål skal leverandøren levere data om alle pengebærende transaktioner og tilhørende bogføringer. Data skal leveres på laveste niveau, fx på CPR-nummer og posterings-niveau. Data skal omfatte alle relevante felter vedr. pengestrømme. Data skal leveres med en frekvens, som specificeres nærmere i samarbejde med ATP. Ved daglige udbetalinger vil kravet være daglige dataleverancer. Data skal leveres til ATP s standardsystem for modtagelse af data i form af e.g txt-filer og data warehouse læsbare filer. I afklaringsfasen skal leverandøren fremlægge en detaljeret redegørelse for pengestrømmene og skal assistere ATP med at definere, hvorledes pengestrømmen f f d il d Rolle, leverandøren Vejledning, leverandøren Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 22 / 66

23 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_179 Afstemning Differencesøgning I tilfælde af at afstemningerne resulterer i differencer, så skal ATP have adgange, redskaber og mulighed for at analysere på de produktive data for at forstå og forklare problemstillingerne. Leverandøren skal give ATP adgang til at kigge direkte i de produktive tabeller, og lave ad hoc udtræk herfra, også selvom der skal joines på flere tabeller. Der skal eksempelvis også kunne initiere en aflevering af afstemningsdata uden om de fastsatte tidskørsler. Leverandøren skal udstille planen for driftsafviklingen, således at afstemningsgruppen kan planlægge udtrækket under hensyn til den daglige drift. I afklaringssfasen skal disse hensyn specificeres nærmere i dialog mellem ATP og leverandøren. Leverandøren skal dokumentere og udstille information til brug for afstemnings- og dataanalyse. I afklaringsfasen skal leverandøren gennemgå de relevante artefakter med ATP. Det skal være muligt at lave udtræk i baggrunden, således at man kan lave udsøgninger samtidigt med at der i systemet kører andre kørsler. Det skal være muligt at schedulere udtræk på forud defineret tidspunkt, således at medarbejderen ikke behøver at lægge sin arbejdstid på selve kørselstidspunktet. Der skal være mulighed for at udsøge posteringer på specifikke selektioner, fx Transaktioner efter en given dato eller en posteringsart mm. og selv at dirigere disse udsøgninger i en CSV fil til et givent fileshare. Rolle Vejledning FUN_180 Afstemning Data erne skal registrere data, så det er muligt at analysere på i tilfælde af fejl. Der skal være en unik identifikationsnøgle mellem de detaildata der udveksles mellem et og øvrige systemer. Leverandøren skal gennemgå disse nøgler med ATP i afklaringssfasen. Nøglerne og medhørende data, skal fremvises til ATP på forlangende og skal udleveres i digitalt format, så den kan bruges i analysearbejde. Der skal være mulighed for at kunne lave aldersopdelte specifikationer. Dvs. posteringer skal indeholde informationer omkring bogføringsdato, bilagsdato, vedr. dato og tidsstempel for hvornår posteringen er oprettet. Der skal være fuld historik på transaktionerne. Det må ikke være muligt at ændre i posteringer, da alle ændringer skal håndteres ved at postere yderligere deltaposter, således at historikken er tilgængelig for ATP. Det skal være simpelt, at kunne supplere med ekstra udtræksfelter, således at ATP uden problemer kan få tilføjet nye variable (hvis der opstår nye felter i leverandørens database FUN_181 K2 Kvittering for indberetning/overførsel Kvitteringssvar fra trediepart for afviste indberetninger/overførsler mv. skal registreres Afstemning således, at der kan ske afstemning med beløb på cpr-niveau mellem og den faktiske indberetning/overførsel., forretningsadministrator FUN_182 Indekssynkronisering Opdatering af indeks et skal afsende data til de fællesoffentlige indekses (Sags og dokumentindeks samt Ydelsesindeks), når en sag oprettes, skifter sagsstatus og når ydelser bevilges og udbetalinger dannes. Se integrationsbeskrivelserne integrationsid FSDI1 - Udstil oplysninger i Sags- og dokumentindeks samt FYDI1 - Udstil oplysninger i Ydelsesindeks., FUN_183 Indekssynkronisering Opdater fra indeks et skal kunne modtage data fra de fællesoffentlige indekses (Sags og dokumentindeks samt Ydelsesindeks), når oplysninger skal hentes af et ifbm. den automatiske sagsbehandling. Se integrationsbeskrivelserne integrationsid FSDI2 - Hent oplysninger fra Sags- og dokumentindeks samt FYDI2 - Hent oplysninger fra Ydelsesindeks. FUN_184 K2 Beskedhåndtering Statusmarkering af besked til borger et skal understøtte, at en på sagen kan se en statusmarkering (fx send med digital/fysisk post), på det som er afsendt fra sagen til den Fællesoffentlige Printløsning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 23 / 66

24 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_185 K2 Beskedhåndtering Modtag information om afsendelsesform fra Fjernprint (digitalt eller fysisk) et skal på hver afsendt besked påsætte en markering tydelig for en, om hvilken afsendelsesform den Fællesoffentlige Printløsning har brugt (fysisk eller digitalt). Rolle Vejledning FUN_186 Beskedhåndtering Konverter besked til PDF et skal konvertere beskeden til PDF før den afsendes til den fællesoffentlige printløsning (Fjernprint). FUN_187 Beskedhåndtering Opret erindring et skal understøtte, at der ved afsendelsen af en besked dannes en erindring, hvis den valgte beskedskabelon, har en erindringsmarkering. FUN_188 FUN_189 Beskedhåndtering Beskedhåndtering Flette informationer i beskedskabelon et skal understøtte, at alle informationer fra Informationsmodel Familieydelser og Sag skal kunne indsættes (flettes) i beskedskabeloner. Derudover skal informationer, som et abonnerer på i Beriget Grunddata, kunne indsættes i beskedskabeloner. Dette gælder uanset, om beskedskabelonerne skal anvendes til automatiske eller manuelle beskeder Flette informationer fra flere breve i samme brev et skal understøtte, at hvis der er flere breve af samme type til samme modtager som sendes samtidig, så skal det kun sendes et brev med informationer fra alle breve. Det gælder også, når breve omhandler forskellige ydelser, men samme forhold fx en partshøring., FUN_190 Beskedhåndtering Afsend besked, et skal afsende beskeden til den Fællesoffentlige Printløsning (Fjernprint). FUN_191 Beskedhåndtering Afsend besked til myndighed, et skal kunne afsende beskeder til myndigheder (Kommuner) via den Fællesoffentlige Printløsning (Fjernprint) eller via Sikker Post. FUN_192 Beskedhåndtering Skjul CPR-nr et skal understøtte, at persons cpr-nr fjernes fra breve til andre private og ved breve til flere parter i samme sag. FUN_193 Beskedhåndtering Koble entydig identifikation til besked et skal til hver afsendt besked koble en entydig identifikation i form af en QR kode indeholdende DokumentIdentifikation på beskeden. Retursvaret fra person skal automatisk journaliseres via QR koden. FUN_194 Beskedhåndtering Journalisering af udsendte beskeder et skal foretage en journalisering af udsendte beskeder på modtagernes sager. Beskederne skal kunne genudskrives som nøjagtige kopier af de udsendte. FUN_195 Hændelser Modtag ændringer fra interne og eksterne registre et skal understøtte, at en kan opsætte/redigere i abonnementer på hændelser, som indgår som et led i en automatiseret proces. Det skal være muligt at redigere i de tilknyttede regler. Hændelserne kan komme fra: * SKAT * Beriget Grunddata * Sags- og dokumentindeks * Pensionssystem * Debitorsystemet * Feriepengeinfo Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 24 / 66

25 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_196 Hændelser Modtag indberetninger fra selvbetjeningsløsningen et skal understøtte, at når der modtage indberetninger (ansøgninger og oplysninger til i gangværende sager) fra selvbetjeningsløsningen, skal den rette proces igangsættes. FUN_197 K0 Hændelser Igangsætning af processer ved interne og eksterne hændelser et skal understøtte igangsættelse af processer når interne eller eksterne hændelser indtræffer, fx flytning, barn fødsel, tid til udsendelse af påmindelse om enlig erklæring mv. FUN_198 Hændelser Opsætning af regler ud fra hændelser et skal understøtte at en forretningsadministrator skal kunne opsætte og redigere i regler, der knytter sig til hændelserne. FUN_199 K2 Hændelser Journalnotat ved hændelser Når en hændelse er modtaget og behandlet i et, skal et danne et automatisk journalnotat om hændelsen og afledte handlinger. FUN_200 K0 Kravgruppe: Grundlæggende funktionalitet FUN_201 Kravgruppe: Grundlæggende funktionalitet FUN_202 Kravgruppe: Grundlæggende funktionalitet FUN_203 K2 Kravgruppe: Grundlæggende funktionalitet FUN_204 Kravgruppe: Grundlæggende funktionalitet Dobbelthistorik ets entiteter skal registreres med dobbelthistorik, Registrering gælder Fra og Til samt Virkning Fra og Til. Registrering ets entiteter skal registreres med angivelse af aktør, Registreringsaktør og Virkningsaktør. Registrering ets entiteter skal registreres med en global unik nøgle. Registrering ets entiteter skal registreres med en status. Komponentmodel Leverandøren skal respektere ets afgrænsninger og levere den fulde funktionalitet inden for ets grænser. ATP har som led i sin kravspecificering udarbejdet en Komponentmodel som er beskrevet i bilag 3A (Behovsopgørelsen). Modellen er ATPs forslag til logisk gruppering af den ønskede forretningsmæssige funktionalitet. Rolle Tilbudsgiver, Leverandør Vejledning Tilbudsgiver må gerne i sin besvarelse af tilbuddet foreslå en anden logisk gruppering af komponenterne indenfor systemet, såfremt dette er bedre i overensstemmelse med den tilbudte løsning. Tilbudsgiver skal i besvarelsen redegøre for sammenhængen mellem den tilbudte løsnings komponentmodel og ATPs komponentmodel. Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 25 / 66

26 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] FUN_205 Kravgruppe: Grundlæggende funktionalitet Kravtekst Kobling til lovgrundlag et skal understøtte at ATP til enhver tid kan dokumentere, på hvilket lovgrundlag en sag er behandlet og en afgørelse er truffet. FUN_206 K2 Kravgruppe: Informationsmodel Logisk datamodel ATP har som led i sin kravspecificering udarbejdet en Informationsmodel for de vigtigste forretningsmæssige begreber og deres sammenhæng. Tilbudsgiver skal med udgangspunkt heri udarbejde en logisk datamodel af alle de data, der skal indeholdes i systemets database. Informationsmodellen er ATPs forslag til logisk gruppering af og sammenhæng i den ønskede forretningsmæssige information. Rolle Tilbudsgiver, Leverandør Vejledning Tilbudsgiver må gerne i sin besvarelse af tilbuddet foreslå en anden logisk gruppering af data, såfremt dette er bedre i overensstemmelse med den tilbudte løsnings komponentopdeling og databasestruktur. Tilbudsgiver skal i besvarelsen redegøre for sammenhængen mellem den tilbudte løsnings databasestruktur og ATPs Informationsmodel. Sker der under implementeringen ændringer til Leverandørens logiske datamodel, skal Leverandøren skriftligt informere ATP herom. FUN_207 K2 Kravgruppe: Informationsmodel Fysisk datamodel ATP har som led i sin kravspecificering udarbejdet en Informationsmodel. Leverandøren skal med udgangspunkt i Informationsmodellen og den logiske datamodel (FUN_206), udarbejde en fysisk datamodel. Det er et krav at Leverandørens fysiske datamodel ikke er i modstrid med ATPs informationsmodel eller den logiske datamodel. Sker der under implementeringen ændringer til Leverandørens fysiske datamodel, skal Leverandøren skriftligt informere ATP herom. Tilbudsgiver, Leverandør FUN_208 K2 Kravgruppe: Informationsmodel Indarbejdelse af tilføjelser til ATPs informationsmodel Der vil i afklaringsfasen formentlig komme tilføjelser/ændringer til ATPs informationsmodel, og leverandøren er forpligtet til at indarbejde de afledte tilføjelser i den logiske datamodel. Tilbudsgiver, Leverandør FUN_209 Kravgruppe: Informationsmodel Historiske data et skal indeholde historiske data til at opfylde de krav, der bliver stillet fra løsningsflows, beregningsregler, beslutningsmodeller og funktionelle krav. FUN_210 Kravgruppe: Informationsmodel Håndtere løbende ændringer i informationsmodeller Leverandøren skal informere ATP om konsekvensen af ændringer i relation til informationsmodeller som led i den almindelige ændringsstyring, jf. Kontraktens bestemmelser om Ændringshåndtering. ATP vedligeholder på baggrund heraf egne informationsmodeller. FUN_211 Kravgruppe: Beslutningsmodeller og regler FUN_212 Kravgruppe: Beslutningsmodeller og regler Lovmedholdelig regler Leverandøren har ansvaret for i samarbejde med ATP, at sørge for at de regler som er implementeret i et, som er udsprunget af lovgivning ("lovregler"), til enhver tid er lovmedholdelige både i udviklings - og driftsperioden. Parallelle regelsæt et skal samtidigt kunne understøtte flere forskellige regelsæt/lovgivninger og efterfølgende bekendtgørelser. Forskellige sager kan således have afgørelser truffet på forskellige lovgrundlag. Leverandør Leverandør Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 26 / 66

27 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_213 Kravgruppe: Løsningsflow Understøttelse af løsningsflows. For de krav, der i det efterfølgende vedrører understøttelse af løsningsflows, skal Leverandøren implementere, teste og levere et, som: Muliggør og ikke hindrer de logiske flow gennem forretningsprocesserne i sin helhed Understøtter de 3 typer af vejnet jf. krav omkring Vejnet og automatisering Overholder ansvarsfordelingen mellem alle lanes i det pågældende løsningsflow Det er acceptabelt, at Leverandøren justerer den konkrete rækkefølge af aktiviteter og foretager sammenlægning eller opbrydning af aktiviteter for at opnå en større grad af udnyttelse af standard funktionalitet og/eller en højere grad af fleksibilitet i den forretningsmæssige løsning. Rolle Leverandør, Vejledning FUN_214 K0 Kravgruppe: Løsningsflow Vejnet og automatisering - motorveje Løsningen skal understøtte fuldautomatisering af processer angivet som Motorveje (grønne pile mellem aktiviteter i løsningsflow). Motorveje er kendetegnet ved processer med stor volumen og hvor fuldautomatisering etableres med positiv business case. FUN_215 Kravgruppe: Løsningsflow Vejnet og automatisering - landeveje Løsningen skal understøtte videst mulig automatisering af processer angivet som Landeveje (blå pile mellem aktiviteter i løsningsflow). Landevejsprocesser er kendetegnet ved at følge de samme aktiviteter som Motorvejene, men særlige hændelser/typer har behov for særskilt behandling i enkelte aktiviteter. FUN_216 Kravgruppe: Løsningsflow Tilbudsgiver skal i sin besvarelse af tilbuddet, beskrive hvilke landeveje leverandørens løsning understøtter automatisering af Vejnet og automatisering - bjergveje Løsningen skal understøtte processer angivet som Bjergveje (røde pile mellem aktiviteter i løsningsflow). Bjergveje er kendetegnet ved, at dele af processen ikke umiddelbart kan helt eller delvist automatiseres. FUN_217 Kravgruppe: Løsningsflow Tilbudsgiver skal i sin besvarelse af tilbuddet, beskrive hvorledes løsningen understøtter bjergveje ved enten manuelle arbejdsgange eller automatisering LF - Familieydelser Håndter indberetning et skal understøtte løsningsflowet i sin helhed FUN_218 Kravgruppe: Løsningsflow LF - Familieydelser Håndter automatisk generede oplysninger et skal understøtte løsningsflowet i sin helhed FUN_219 Kravgruppe: Løsningsflow LF - Familieydelser Træf afgørelse et skal understøtte løsningsflowet i sin helhed FUN_220 Kravgruppe: Løsningsflow LF - Familieydelser Dan udbetalingsgrundlag et skal understøtte løsningsflowet i sin helhed FUN_221 Kravgruppe: Løsningsflow LF - Familieydelser Udsend påmindelse om enlig-erklæring et skal understøtte løsningsflowet i sin helhed FUN_222 Kravgruppe: Løsningsflow LF - Familieydelser Effektuer udbetaling et skal understøtte løsningsflowet i sin helhed FUN_223 Kravgruppe: Løsningsflow LF - Familieydelser Dan krav et skal understøtte løsningsflowet i sin helhed FUN_224 K2 Kravgruppe: Løsningssubflow LSF Modtag post et skal understøtte løsningsflowet i sin helhed FUN_225 K2 Kravgruppe: Løsningssubflow LSF Afsend post et skal understøtte løsningsflowet i sin helhed FUN_226 Kravgruppe: Løsningssubflow LSF Modtag telefonopkald et skal understøtte løsningsflowet i sin helhed FUN_227 Kravgruppe: Løsningssubflow LSF Foretag telefonopkald et skal understøtte løsningsflowet i sin helhed FUN_228 Kravgruppe: Løsningssubflow LSF Modtag dataleverancer et skal understøtte løsningsflowet i sin helhed FUN_229 Kravgruppe: Løsningssubflow LSF Afsend dataleverancer et skal understøtte løsningsflowet i sin helhed Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 27 / 66

28 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_230 Kravgruppe: Løsningssubflow LSF Modtag henvendelse via WWW et skal understøtte løsningsflowet i sin helhed FUN_231 Kravgruppe: Løsningssubflow LSF Modtag log-in oplysninger et skal understøtte løsningsflowet i sin helhed FUN_232 Kravgruppe: Løsningssubflow LSF Foretag webservicekald et skal understøtte løsningsflowet i sin helhed FUN_233 Kravgruppe: Aktivitetsbeskrivelser Understøttelse af aktiviteter i løsningsflows For de aktiviteter der indgår i løsningsflows (gule), skal Leverandøren implementere, teste og levere: En opsætning af regler og beregninger samt proceskrav beskrevet i punktet Regler i den pågældende aktivitetsbeskrivelse Leverandør, FUN_234 Kravgruppe: Aktivitetsbeskrivelser FUN_235 Kravgruppe: Aktivitetsbeskrivelser Understøttelse af aktiviteter i løsningsflows Leverandør, For de aktiviteter der indgår i løsningsflows (gule), skal Leverandøren implementere, teste og levere: En logisk og fysisk datamodel, der kan rumme de data der skal anvendes i fobindelse med udførelse af aktiviteten Understøttelse af aktiviteter i løsningsflows Leverandør, For de aktiviteter der indgår i løsningsflows (gule), skal Leverandøren implementere, teste og levere: Funktionalitet til at understøtte behovet for systemunderstøttelse i den pågældende aktivitetsbeskrivelse FUN_236 K0 Dan opkrævning Entydigt ID et skal ved oprettelse af krav tilknytte et entydigt ID til kravet. FUN_237 K0 Dan opkrævning Ændring af krav Når et krav ændres og bliver mindre, skal et oprette et nyt negativt krav med samme ID som det oprindelige. FUN_238 K0 Dan opkrævning Ændring af krav Når et krav ændres og bliver større, skal et oprette et nyt krav med et nyt ID. Det nye krav skal ud fra ID'et entydigt kunne kobles med det oprindelige krav. De to krav skal begge kunne kobles til den tilhørende afgørelse i et. FUN_239 K2 Modregning Passivering af modregningsordning Når en modregningsordning udløber og der er ikke er sket modregning skal aftalen passiveres, og et skal sende besked til Debitor om at modregning ikke er foretaget. FUN_240 Modregning Modregning ID Når et modtager modregningsordninger via Debitor er der tilknyttet et entydig ID på modregningsordningen. Dette ID skal følge al information mellem Debitor og Familieydelsessystemet omkring modregningen. FUN_241 K2 Modregning Modregning - forfaldsdato for modregningsordning Modregning skal tidligst ske når Debitors forfaldsdato (jf Debitors informationsmodel) er nået. FUN_242 Dan opkrævning Send krav til Debitor Når et krav er dannet i Familieydelsessystemet skal et umiddelbart efter sendes til Debitor. Det ID som er dannet i et ved oprettelsen af kravet skal ligeledes sendes til Debitor. Rolle Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 28 / 66

29 Krav ID Krav type Komponent [xx] Kravgruppe [Kravgruppe: xx] Kravtekst FUN_243 K0 Selvbetjening Modtagelse af data Når en Person har udfyldt og indsendt oplysninger via Selvbetjeningsløsningen skal data gemmes i systemet, og hvor det er muligt skal data gemmes direkte på sagen. FUN_244 Selvbetjening Udstilling af data På borger.dk skal der via Min side udstilles essentielle udbetalingsoplysninger (fx næste udbetaling og dato), samt link til Selvbetjeningsløsningen, hvor alle data og evt. status vises. Data forventes hentet fra Sags- og ydelsesindekset. FUN_245 Arkivering Påføring af kassationskoder ved oprettelse af sager et skal understøtte at der påføres en kassationskode, når en sag oprettes. Regler for kassation skal opsættes, som en del af forretningsreglerne for Familieydelser. FUN_246 K2 Arkivering Visning af sager der er markeret til Kassation Sager der er lukkede og dermed markeret til kassation skal kunne vises i et, med markering af, hvornår sagen slettes. FUN_247 K2 Arkivering Forlængelse af frist for sletning af en sag et skal understøtte at en frist for sletning af en sag kan forlænges. Det skal kunne ske enten for en gruppe af sager eller ved at en udvælger enkelte sager. FUN_248 K2 Arkivering Sletning af sager et skal ud fra tidsbestemte kørsler kunne foretage et gennemløb på samtlige sager i et, og de sager hvor fristen for sletning er nået, skal slettes. FUN_249 K2 Arkivering Sletning af parter der ikke har tilknyttede sager eller relationer et skal i forbindelse med sletning af sager (se krav ovenfor) gennemløbe parter på de sager der slettes, og herefter slette de parter, der ikke længere har tilknyttede sager eller relationer. Rolle Vejledning Funktionelle krav Bilag 03A.1 - Kravliste.xlsx Side 29 / 66

30 Non-funktionelle krav Krav ID Kravgruppe Underkrav-gruppe relateret NFK_001 Arkitektur Arkitekturprincipper et skal efterleve ATP's arkitekturprincipper, jf. bilag 3 (Leverancebeskrivelse). Krav-type Formål med kravet Kravtekst Tilbudsgiver skal redegøre for, hvor og hvordan man kan se at arkitekturprincipperne er indarbejdet i et. NFK_002 Arkitektur Arkitekturprincipper Formålet er at sikre at veldefinerede processer ved anvendelse af redundante data, hvilket er et aspekt under arkitekturprincip nummer 5. et skal genbruge data ved træk på autoritative kilder og fællesoffentlige registre. NFK_003 Arkitektur Belastning X Formålet er at kvantificere fra et kapacitetssynspunkt for, hvordan et benyttes og af hvor mange. NFK_004 Arkitektur Belastning X Formålet er at kvantificere fra et kapacitetssynspunkt for, hvordan et benyttes og af hvor mange. NFK_005 Arkitektur Data X K2 Formålet er at sikre en effektiv drift og sikkerheden i et. et skal understøtte den nuværende årlige belastning i forbindelse med administration af Familieydelsesområdet, jf. bilag 2 (Situationsbeskrivelse). et skal understøtte følgende årlige belastning i antallet af henvendelser, jf. bilag 3A (Behovsopgørelse), i forbindelse med administration af Familieydelsesområdet. Leverandøren skal levere et, hvor applikation og data holdes adskilt. Leverandørens besvarelse Løsningsmåde NFK_006 Arkitektur Data X K2 Formålet er at sikre Hvis et anvender replikerede data, skal det sikre, at permanente datakonsistens og dataejerskab. ændringer sker i dataejerens kildesystem, og ikke kun i den replikerede kopi. NFK_007 Arkitektur Data X K2 Formålet er at et kan modtage og behandle dokumenter og billeder NFK_008 Arkitektur Data X K2 Formålet er at et kan videresende dokumenter og billeder til posthåndteringsleverandøren, jf. bilag 3A.6 (Integrationer). NFK_009 Arkitektur Data X K2 Formålet er at et kan modtage og behandle dokumenter og billeder NFK_010 Arkitektur Data X K2 Formålet at at kunne tilpasse brugergrænsefladen til borgere. Vi forestiller os, at der med tiden kommer nye relevante kanaler, som vi på nuværende tidspunkt ikke kender til, muligvis også i perioden fra udbudsmaterialet frigives til løsningerne implementeres NFK_011 Arkitektur Integrationer X K2 Formålet er at sikre, at Services er indkapslet et skal som minimum kunne modtage og persistere de mest gængse filformater (Fx TXT, DOC, DOCX, ODT, PDF, PPT, PPTX, XLS, XLSX, XML, BMP, GIF, JPG, PNG og TIFF). et skal kunne videresende de mest gængse filformater til Fjernprint, jf. bilag 3A.6 (Integrationer). et skal understøtte modtagelse og persistering af filer, f.eks. i forbindelse med modtagelse af vedhæftede dokumenter fra selvbetjeningsløsningen. Det skal være muligt at konfigurere øvre størrelse på filer, der kan behandles af et et skal understøtte, at man kan ændre i eller tilføje nye kanaler, uden at det kræver ændringer i designet for de øvrige eksisterende kanaler. Med kanaler menes de forskellige klientenheder ("devices") som anvendes til at tilgå henholdsvis fagsystemet og selvbetjeningsløsningen. Leverandøren skal designe et, så services er indkapslet. Det betyder, at serviceanvendere ikke skal være bekendt med, hvordan servicen er implementeret. Ved services forstås funktionalitet, som er tilgængeligt igennem snitflader eller systeminterfaces. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 30 / 66

31 Krav ID Kravgruppe Underkrav-gruppe relateret NFK_012 Arkitektur Integrationer X Formålet er at sikre, at Leverandøren har ansvaret for etablering af de nødvendige integrationer. NFK_013 Arkitektur Integrationer X Formålet er at sikre, at et benytter de samme persondata og myndighedsoplysninger, som de øvrige ordningssystemer i Udbetaling Danmark. Krav-type Formål med kravet Kravtekst Etablering af integrationer Leverandøren skal etablere, implementere, teste og levere de integrationer mellem et og øvrige komponenter, som er nødvendige for understøttelse af ets funktionalitet. Leverandøren skal herunder etablere og levere den nødvendige tekniske infrastruktur til integrationerne. Integrationerne skal implementeres, så de sikrer overholdelsen af krav til servicemål, jf. bilag 7 (Servicemål), og non-funktionelle krav vedrørende integrationer, herunder indenfor områderne arkitektur, design og applikationsstruktur, sikkerhed og robusthed. Integrationerne skal implementeres, så de kan håndtere de volumener, der er angivet under de k lt i t ti Integration til Beriget grunddata et skal anvende persondata og myndighedsoplysninger fra Beriget Grunddata, og hente disse oplysninger via en integration, som beskrevet i integrationsbeskrivelse FBGD1 i bilag 3A.6 (Integrationer). Løsningsmåde NFK_014 Arkitektur Integrationer X Formålet er at sikre, at posteringsoplysninger overføres automatisk til ATP ERP, således at økonomiopfølgning kan foretages i ATP's ERP-system. Integration til ATP ERP et skal automatisk overføre posteringsoplysninger til ATP ERP via en integration, som beskrevet i integrationsbeskrivelse FERP1 i bilag 3A.6 (Integrationer). NFK_015 Arkitektur Integrationer X Formålet er at sikre, at ATPs afstemnings-enhed automatisk modtager de fornødne data. NFK_016 Arkitektur Integrationer X Formålet er at sikre at data automatisk leveres til ATP's Datawarehouse, således at ledelsesrapportering kan foretages i ATP's Datawarehouse NFK_017 Arkitektur Integrationer X Formålet er at sikre at en testleverance af data til ATP's Datawarehouse. NFK_018 Arkitektur Integrationer X Formålet er at sikre at ATP's proces for vedligeholdelse af brugere og deres rettigheder understøttes af et. NFK_019 Arkitektur Integrationer X Formålet er at sikre, at integrationer til ATPs systemer benytter ATPs integrationsplatform. Levering af data til ATP afstemning et skal automatisk levere data til brug for den regnskabsmæssige kontrol og afstemning, som beskrevet i integrationsbeskrivelse FAAF1 i bilag 3A.6 (Integrationer). Levering af data til Datawarehouse et skal overføre data til ATP's Datawarehouse, som beskrevet i integrationsbeskrivelse FDWH1 i bilag 3A.6 (Integrationer). Lever testdataleverance Leverandøren skal senest 6 måneder før idriftsættelse sætte en fuld test dataleverance til rådighed for ATP's Datawarehouse. Integration til ATP's IdM og IdP et skal benytte sig af de oplysninger om brugere og deres rolletildelinger, som findes og vedligeholdes i ATP IdM og IdP. Dette skal ske via integration til ATP IdM og IdP, som beskrevet i integrationsbeskrivelse FIDM1, FIDP1 i bilag 3A.6 (Integrationer). Integration til ATPs systemer via integrationsplatformen EKKO et skal integrere til ATP-interne systemer via ATP's integrationsplatform EKKO. Dette gælder for nedenstående integrationer: - FERP1 - Levering af data til ATP ERP. - FAAF1 - Levering af data til ATP afstemning. - FDWH1 - Levering af data til ATP Data warehouse. FBGD1 Integration til Beriget Grunddata Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 31 / 66

32 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_020 Arkitektur Integrationer X Formålet er at sikre, at integrationer til ATPs systemer overholder ATPs sikkerhedskrav. Tilladte batch-integrationsformer via ATP's integrationsplatform EKKO et skal benytte en af nedenstående integrationsformer/transportteknologier ved batch-integrationer over ATP's integrationsplatform EKKO. - FTP over VPN - HTTP over VPN - MQ over VPN - MQ med OCES Certifikat - SFTP med OCES Certifikat - HTTPS WSS ( WebService Secure) - HTTPS OIO-IDWS - Connect Direct NFK_021 Arkitektur Integrationer X Formålet er at sikre, at integrationer til ATPs systemer overholder ATPs sikkerhedskrav. Tilladte online-integrationsformer via ATP's integrationsplatform EKKO et skal benytte en af nedenstående integrationsformer/transportteknologier ved online integrationer over ATP's integrationsplatform: - HTTP over VPN - MQ over VPN - OIO IDWS SAML NFK_022 Arkitektur Integrationer X Formålet er at sikre, at der automatisk indberettes oplysninger til SU. Integration til SU Styrelsen et skal udtrække og aflevere data til SU, som beskrevet i integrationsbeskrivelse FSUS1 i bilag 3A.6 (Integrationer). NFK_023 Arkitektur Integrationer X Formålet er at sikre at der automatisk hentes topskattegrundlag og skattepligtskode. Integration til SKAT Forskud et skal automatisk via integration indhente topskattegrundlag og skattepligtskode fra SKAT Forskud, som beskrevet i integrationsbeskrivelse FSKF1 og FSKF2 i bilag 3A.6 (Integrationer). NFK_024 Arkitektur Integrationer X Formålet er at sikre at der automatisk hentes topskattegrundlag. NFK_025 Arkitektur Integrationer X Formålet er at sikre at der altid anvendes opdaterede indkomstoplysninger ved behandling af familieydelser. NFK_026 Arkitektur Integrationer X Formålet er at sikre, at der automatisk leveres de lovpligtige oplysninger til SKAT Enlige forsørgere. NFK_027 Arkitektur Integrationer X Formålet er at sikre, at breve og digitale beskeder afsendes automatisk og på en ensartet måde. NFK_028 Arkitektur Integrationer X Formålet er at sikre, at der automatisk leveres de lovpligtige oplysninger til SKAT Grøn Check. NFK_029 Arkitektur Integrationer X Formålet er at sikre, at der automatisk leveres de lovpligtige oplysninger til SKAT EFI. Integration til SKAT Årsopgørelse et skal via integration automatisk indhente topskattegrundlag fra SKAT Årsopgørelse, som beskrevet i integrationsbeskrivelse FSKS1 i bilag 3A.6 (Integrationer). Integration til SKAT eindkomst - hent indkomstoplysninger et skal via integration automatisk hente indkomstoplysninger, herunder optjeningsprocent, fra eindkomst, som beskrevet i integrationsbeskrivelse FSKE1 i bilag 3A.6 (Integrationer). Integration til SKAT Enlige forsørgere et skal udtrække og aflevere data til SKAT Enlige forsørgere, som beskrevet i integrationsbeskrivelse FSEF1 i bilag 3A.6 (Integrationer). Integration til Fjernprint et skal anvende den fællesoffentlige fjernprintløsning til afsendelse af fysisk og digital post samt afgørelse af hvilken kanal, en besked sendes igennem, via en integration til Fjernprint, som beskrevet i integrationsbeskrivelse FFPR1 i bilag 3A.6 (Integrationer). Integration til SKAT Grøn Check et skal udtrække og aflevere data til SKAT Grøn Check, som beskrevet i integrationsbeskrivelse FSGR1 og FSGR2 i bilag 3A.6 (Integrationer). Integration til SKAT EFI et skal udtrække og aflevere data til SKAT EFI, som beskrevet i integrationsbeskrivelse FEFI1 i bilag 3A.6 (Integrationer). Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 32 / 66

33 Krav ID Kravgruppe Underkrav-gruppe relateret NFK_030 Arkitektur Integrationer X Formålet er at sikre at udbetalinger håndteres automatisk. NFK_031 Arkitektur Integrationer X Formålet er at sikre, at der automatisk hentes digitale fuldmagter. NFK_032 Arkitektur Integrationer X Formålet er at sikre, at der automatisk hentes oplysninger om pensionister. NFK_033 Arkitektur Integrationer X Formålet er at sikre, at der automatisk leveres de lovpligtige oplysninger til Danmarks Statistik. Krav-type Formål med kravet Kravtekst NFK_034 Arkitektur Integrationer X Formålet er at sikre, at der automatisk indberettes skattefrie udbetalinger til SKAT. Integration til NemKonto et skal benytte Nemkonto til at gennemføre udbetalinger og skal gøre dette via en integration til NemKonto som beskrevet i integrationsbeskrivelse FNKS1 i bilag 3A.6 (Integrationer). Integration til Digital Fuldmagt et skal integrere og hente digitale fuldmagter, som beskrevet i integrationsbeskrivelse FDIF1 i bilag 3A.6 (Integrationer). Integration til Pensionsfagsystemet et skal indhenter oplysninger omkring pensionister, som beskrevet i integrationsbeskrivelse FPFS1 i bilag 3A.6 (Integrationer). Levering af data til Danmarks Statistik et skal udtrække og aflevere data til Danmarks Statistik, som beskrevet i integrationsbeskrivelse FDST1 i bilag 3A.6 (Integrationer). Levering af data til SKAT (CSC) et skal udtrække og aflevere data til SKAT (CSC), som beskrevet i integrationsbeskrivelse FSKA1 i bilag 3A.6 (Integrationer). Løsningsmåde NFK_035 Arkitektur Integrationer X Formålet er at sikre, at der automatisk afsendes datawarehousedata til SKAT. NFK_036 Arkitektur Integrationer X Formålet er at sikre autentifikation af Selvbetjeningsløsningens brugere. Levering af data til SKAT Datawarehouse et skal udtrække og aflevere data til SKAT Datawarehouse, som beskrevet i integrationsbeskrivelse FSBI1 i bilag 3A.6 (Integrationer). Autentifikation af brugere via NemLog-in Selvbetjeningsløsningen skal autentificere de brugere, som tilgår de ikkeoffentlige dele af Selvbetjeningsløsningen via integration til NemLog-in, som beskrevet i integrationsbeskrivelse FNLO1 i bilag 3A.6 (Integrationer). NFK_037 Arkitektur Integrationer X MK Formålet er at sikre overholdelse af NemLog-ins politikker og tekniske krav. NFK_038 Arkitektur Integrationer X Formålet er at sikre at Selvbetjeningsløsninger bliver udstillet via Borger.dk. NFK_039 Arkitektur Integrationer X Formålet er at sikre at der vedligeholdes et sagsoverblik i sagsindekset. Overholdelse af NemLog-ins politikker og tekniske krav Leverandøren skal ved integration til NemLog-in overholde de tekniske krav og politikker, som er defineret af Digitaliseringsstyrelsen, se reference i bilag 3A.6 (Integrationer). Dette inkluderer: - Integrationstest ved tilslutning til NemLog-in, Version Certifikatpolitik for NemLog-in, version Logningspolitik, version Timeout politik, version Politik for tidssætning, version 1.1 Integration til Borger.dk Selvbetjeningsløsningen skal udstilles via Borger.dk, som beskrevet i integrationsbeskrivelse FBOR1 i bilag 3A.6 (Integrationer). Integration til Sags- og dokumentindekse - Udstil sager og dokumenter et skal automatisk sende opdateringer til sager og dokumenter til Sags- og dokumentindeks, som beskrevet i integrationsbeskrivelse FSDI1 i bilag 3A.6 (Integrationer). NFK_040 Arkitektur Integrationer X Formålet er at få adgang til data til sagsoverblikket. NFK_041 Arkitektur Integrationer X Formålet er at sikre at der udstilles de fornødne udbetalingsoplysninger i Ydelsesindekset. Integration til Sags- og dokumentindeks - Hent oplysninger et skal kunne hente metadata om sager og dokumenter fra Sags- og dokumentindeks, som beskrevet i integrationsbeskrivelse FSDI2 i bilag 3A.6 (Integrationer). Integration til Ydelsesindeks - Udstilling af oplysninger et skal automatisk sende opdateringer til bevillinger og ydelser til Ydelsesindeks, som beskrevet i integrationsbeskrivelse FYDI1 i bilag 3A.6 (Integrationer). Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 33 / 66

34 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_042 Arkitektur Integrationer X Formålet er at få adgang til data til ydelsesoverblikket. NFK_043 Arkitektur Integrationer X Formålet er at sikre at systemet kan modtage indgående post/beskeder, som skal journaliseres på familieydelsessagen. Integration til Ydelsesindeks - Hentning af oplysninger et skal kunne hente metadata om bevillinger og ydelser fra Ydelsesindeks, som beskrevet i integrationsbeskrivelse FYDI2 i bilag 3A.6 (Integrationer). Integration til Posthåndteringsleverandøren - Modtag indgående post et skal automatisk kunne modtage dokumenter, som skal journaliseres enten på en eksisterende sag eller en ny sag, som beskrevet i integrationsbeskrivelse FPHL1 i bilag 3A.6 (Integrationer). NFK_044 Arkitektur Integrationer X Formålet er at sikre, at et kan returnere post/beskeder, som skal journaliseres et andet sted. NFK_045 Arkitektur Integrationer X Formålet er at sikre, at krav og svar på krav automatisk udveksles med opkrævningen. NFK_046 Arkitektur Integrationer X Formålet er at sikre, at modregninger og svar på modregninger automatisk udveksles med opkrævningen. Integration til Posthåndteringsleverandøren - Send post til genjournalisering et skal sende dokumenter som skal genjournaliseres til Posthåndteringsleverandøren, som beskrevet i integrationsbeskrivelse FPHL2 i bilag 3A.6 (Integrationer). Integration til Debitor omkring krav et skal automatisk oprette krav og få statussvar tilbage via integration til debitorsystemet, som beskrevet i integrationsbeskrivelse FOFS1 og FOFS2 i bilag 3A.6 (Integrationer). Integration til Debitor omkring modregninger et skal automatisk modtage modregninger og sende statussvar tilbage via integration til debitorsystemet, som beskrevet i integrationsbeskrivelse FOFS3 og FOFS4 i bilag 3A.6 (Integrationer). NFK_047 Arkitektur Integrationer X Formålet er at sikre, at der automatisk indberettes oplysninger til BLIS. NFK_048 Arkitektur Integrationer X Formålet er at sikre, at et kan sende beskeder via kanalen Sikker Post. NFK_049 Arkitektur Integrationer X Formålet er at sikre, at et kan modtage information fra Feriepenge.dk Integration til Ministeriet for Børn, Ligestilling, Integration & Social Forhold (BLIS) et skal udtrække og aflevere data til BLIS, som beskrevet i integrationsbeskrivelse FBLI1 i bilag 3A.6 (Integrationer). Integration til Sikker Post et skal kunne sende beskeder til myndigheder via integrationen til Sikker Post. Integrationen imellem et og ATPs mailserver skal ske ved at mailen routing fra et til ATPs mailserver via en sikker forbindelse eksempelvis (TLS/SSL, VPN), som beskrevet i integrationen FSIP1 i bilag 3A 6 (Integrationer) Integration til Feriepenge.dk et skal kunne modtage data fra Feriepenge.dk, som beskrevet i integrationsbeskrivelse FFEP1 i bilag 3A.6 (Integrationer). NFK_050 Arkitektur Skalering X Formålet er, at sikre ets skalerbarhed, og at der leveres en skaleringsstrategi NFK_051 Arkitektur Skalering X K2 Formålet er at kvantificere fra et kapacitetssynspunkt for, hvordan et benyttes og af hvor mange. Leverandøren skal designe og udvikle et således, at et i den efterfølgende drift kan skaleres. Skaleringen skal sikre, at et kan håndtere et stigende antal brugere og datamængder samtidig med at de aftalte servicemål for driften, jf. bilag 7 (Servicemål) til enhver tid overholdes et skal generelt kunne håndtere en stigning i henvendelser (telefonopkald, breve, blanketter samt digital post) pr. år på 10 % i forhold til den nuværende belastning, jf. bilag 3A (Behovsopgørelse). et skal specielt for håndtering af Digital Post kunne håndtere en forøgelse på 250 % i forhold til i dag jævnt fordelt over 3 år. Samtidig forventes antallet af indkommende manuelle breve at aftage med 50% i forhold til i dag jævnt fordelt over 3 år. NFK_052 Arkitektur Standardisering Formålet er at sikre at et anvender modne teknologier et skal anvende markedsudbredte, veletablerede, supporterede og gennemprøvede teknologier. Hvor der findes en standardløsning, bør denne være det foretrukne valg. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 34 / 66

35 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_053 Arkitektur Standardisering Formålet er at sikre en effektiv forvaltning af et. et skal benytte officielle og dokumenterede funktionaliteter fra standardsystemer og tredjepartskomponenter. NFK_054 Arkitektur Standardisering X K2 Formålet er benytte OIO-Sag og Dokumentstandarderne NFK_055 Arkitektur Standardisering K2 Formålet er at skabe mulighed for lokal udvidelse ad OIO-Sag og Dokumentstandarden NFK_056 Arkitektur Standardisering Formålet er at følge de offentlige standarder, som både Udbetaling Danmark og ATP som myndighed er underlagt. Hvis Leverandøren ønsker at benytte et API eller en funktionalitet, som ikke er en officiel del af standardsystemet eller tredjepartskomponent, så skal dette aftales med ATP et skal basere udvekslingen af Sager og Dokumenter på de OIOgodkendte Standarder for Sag og Dokument, således at det sikres, at 3. parts systemer kan hente og/eller modtage Sager og Dokumenter via udstillede services. Leverandøren skal foretage lokal udvidelse af OIO-sag og Dokumentstandarden, såfremt den fagspecifikke sag eller dokument, kræver yderligere attributter eller relationer, end der eksisterer i standarden. Lokale udvidelser skal godkendes af ATP. et skal overholde følgende offentlige standarder: - Standarder for dataudveksling mellem offentlige myndigheder (OIOXML) - Standarder for digital signatur (OCES + OCES-II) - Standarder til elektronisk sags- og dokumenthåndtering (FESD) - Standarder til elektroniske indkøb i det offentlige (OIOUBL) - Standarder for ISO Standarder for dokumentudveksling (ODF/OOXML) - B103 åbne standarder for software i det offentlige Uddybende beskrivelser findes her: NFK_057 Brugervenlighed Generelt X Formålet er at understøtte Selvbetjeningsløsningen skal understøtte princippet om, at brugeren ikke princippet om, at brugeren ikke skal spørges om oplysninger, som findes i bagvedliggende systemer eller skal spørges om oplysninger som kan hentes fra andre offentlige registre. som findes i forvejen. Denne type oplysninger skal et præsentere for brugeren, når denne logger på selvbetjeningsløsningen. NFK_058 Brugervenlighed Generelt X K2 Formålet er at sikre, at selvbetjeningsløsningen overholder kravene i Udviklingsvejledningen for velfungerende selvbetjeningsløsninger NFK_059 Brugervenlighed Layout X Formålet er at sikre, at obligatoriske indtastningsfelter bliver markeret tydeligt Selvbetjeningsløsningen skal kunne overholde Udviklingsvejledningen for velfungerende selvbetjeningsløsninger (jf. initiativ 1.5 i Den fællesoffentlige digitaliseringsstrategi), jf. Indtastningsfelter, som brugeren skal udfylde, dvs. obligatoriske felter, skal markeres tydeligt. Dette krav gælder fagsystemet. NFK_060 Brugervenlighed Layout X K2 Formålet er at sikre et godt arbejdsmiljø, der lever op til Arbejdstilsynets vejledning "ATvejledning om skærmarbejde" Brugergrænsefladen i fagsystemet skal udstille skrift i font 10 eller større. NFK_061 Brugervenlighed Layout X K2 Formålet er at sikre et godt arbejdsmiljø, der lever op til Arbejdstilsynets vejledning "ATvejledning om skærmarbejde" Brugergrænsefladen i fagsystemet skal benytte farver, der ikke begrænser farveblinde i brugen afet. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 35 / 66

36 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_062 Brugervenlighed Layout X K2 Formålet er at sikre at Leverandøren skal designe selvbetjeningsløsningen i samarbejde med ATP. Selvbetjeningsløsninger bliver bliver udarbejdet i samarbejde. NFK_063 Brugervenlighed Meddelelser & fejlhåndtering X K2 Formålet er at sikre, at utilgængelige skærmobjekter bliver sløret for brugeren et skal sløre skærmobjekter, fx knapper og indtastningsfelter, som midlertidigt ikke er tilgængelige for brugeren. Hjælp til et sløret skærmobjekt skal tydeligt forklare, hvorfor skærmobjektet ikke er tilgængeligt, og hvad brugeren skal gøre for at gøre skærmobjektet tilgængeligt. NFK_064 Brugervenlighed Meddelelser & fejlhåndtering X K2 Formålet er at sikre, at et informerer brugeren, når svartiden for en side overskrider svartidskravene. Dette krav gælder både fagsystemet og selvbetjeningsløsningen et skal sikre, at når svartiden for en side bliver længere end standardsvartiden, så skal brugeren kunne se, at processen er i gang, fx ved at skrive til brugeren den forventede procestid. Brugeren skal ligeledes informeres, hvis eksterne datakilder ikke er tilgængelige, ligesom brugeren skal informeres, når et er igang med at behandle en forespørgsel fra brugeren. NFK_065 Brugervenlighed Meddelelser & fejlhåndtering X K2 Formålet er at forebygge typiske fejl i fagsystemet og selvbetjeningsløsningen Dette krav gælder både fagsystemet og selvbetjeningsløsningen Leverandøren skal sikre, at fagsystemet og selvbetjeningsløsningen forebygger typiske fejl, fx: - At brugere vælger værdier i stedet for at indtaste dem. - Hvor det er muligt, foreslår et automatisk den mest sandsynlige, gyldige værdi for et felt. NFK_066 Brugervenlighed Meddelelser & fejlhåndtering K2 Formålet er, at ATP kan formulere og opdaterer tekster og meddelelser i et. I fagsystemet må forebyggende foranstaltninger ikke i væsentlig grad påvirke effektiviteten Leverandøren skal levere et oplæg på fejlmeddelelser og tekster mv, som vises i et. et skal overalt anvende samme ord for samme begreb. ATP skal have adgang til at kunne redigere tekster, hjælpetekster, statusog fejlmeddelelser ved hjælp af et tekstredigeringsværktøj svarende til redigeringsværktøj som kendes fra fx content management-systemer. I ets hjælpetekster skal det endvidere være muligt at indsætte links til eksterne informationskilder, herunder ATP's videnløsning. NFK_067 Brugervenlighed Meddelelser & fejlhåndtering NFK_068 Brugervenlighed Meddelelser & fejlhåndtering NFK_069 Brugervenlighed Meddelelser & fejlhåndtering X K2 Formålet er at sikre, at et skal sikre, at brugere ikke utilsigtet kan miste mere end ca. 1 et gemmer indtasninger minuts arbejde ved et uheld. Eksempler: Brugere forlader deres ved teknisk fejl i kommunikationen arbejdsplads i en periode som er længere end time-out, eller der opstår en intern fejl i systemet, eller strømmen svigter. X Formålet et at sikre, at brugerne ser en tydelig markering af de handlinger der udføres i fagsystemet X K2 Formålet er at sikre et godt arbejdsmiljø, der lever op til Arbejdstilsynets vejledning "ATvejledning om skærmarbejde" Dette krav gælder fagsystemet et skal sikre at brugeren tydeligt gøres opmærksom på fejl eller mangler i indtastninger og at brugeren ikke skal bekræfte trivielle eller rutinemæssige operationer i fagsystemet. Fagsystemet skal indeholde hjælpefunktioner og -information, som er tilgængelig for brugeren. Brugeren skal have mulighed for at til- og fravælge at få vist processuel hjælpeinformation, fx i form af pop-up vinduer til felter og instrukser. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 36 / 66

37 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_070 Brugervenlighed Meddelelser & fejlhåndtering X K2 Formålet er at give brugeren adgang til selvbetjeningsløsningen, selv om borger.dk er utilgængelig Selvbetjeningsløsningen skal - i tilfælde af at borger.dk er utilgængelig - kunne fungere uafhængigt af borger.dk og brugeren skal kunne tilgå selvbetjeningsløsningen direkte ved at klikke på link i f.eks. s eller på ATP's / Udbetaling Danmarks website. NFK_071 Brugervenlighed Navigation & interaktion X K2 Formålet er at opnå en logisk placering af cursoren på brugerens skærmbillede. NFK_072 Brugervenlighed Navigation & interaktion X K2 Formålet er at sikre, at et opføre sig ensartet ved brug af Enter. et skal placere cursor i det indtastningsfelt på skærmbilledet, der naturligt behandles først i den mest typiske brugssituation. Dette krav gælder fagsystemet. et skal opføre sig ensartet ved brug af Enter-tasten. På hvert skærmbillede skal én knap være fremhævet. Den fremhævede knap skal svare til den hyppigst anvendte eller sikreste brugerfunktion. At bruge Enter-tasten på tastaturet skal svare til at klikke på den fremhævede knap. NFK_073 Brugervenlighed Navigation & interaktion X K2 Formålet er at sikre et godt Dette krav gælder fagsystemet Brugergrænsefladen i fagsystemet skal have genvejstaster til de mest arbejdsmiljø, der lever op til Arbejdstilsynets vejledning "ATvejledning om skærmarbejde" brugte funktioner. Genvejstaster skal så vidt muligt kunne aktiveres, uden at brugeren skal NFK_074 Brugervenlighed Navigation & interaktion X K2 Formålet er at sikre smidighed og effektivitet i ens daglige arbejde. NFK_075 Brugervenlighed Teknisk krav MK Formålet er at definere sprogunderstøttelsen i et trykke på to knapper samtidig. et skal gøre det muligt for ATP s forretningsadministratorer at foretage konfigurering af skærmbilledeopbygning i søgeskærmbilleder med hensyn til visning og rækkefølge af felter, således at konfigurationen gælder for alle brugere af fagsystemet. Brugerne skal kunne tilgå et og selvbetjeningsløsningen på dansk. et skal være forberedt til at kunne understøtte flere sprog udover dansk (fx engelsk). Implementeringen vil dog i første omgang alene ske på dansk. NFK_076 Brugervenlighed Teknisk krav X K2 Formålet er at sikre at de webbaserede funktioner, som udgangspunkt er uafhængig af applets eller andre plug-ins NFK_077 Brugervenlighed Teknisk krav X K2 Formålet er at sikre, at fagsystemet fungerer ved forskellige skærm-opløsninger. NFK_078 Brugervenlighed Teknisk krav X K2 Formålet er at sikre, at klientbaseret software kan installeres på ATPs PC-platform. NFK_079 Brugervenlighed Teknisk krav X K2 Formålet er at sikre, at et fremtræder ens på flest mulige platforme. NFK_080 Brugervenlighed Teknisk krav X K2 Formålet er at sikre, at der er tilgængelighed ved opfyldelse af WCAG 2.0 Level AA Brugergrænseflader, der vises i en browser, skal som udgangspunkt være fri for applets eller andre plug-ins. Skærmbillederne i fagsystemet skal virke optimalt ved 1280*1024 opløsning, men de skal være lavet efter et responsivt design, så indholdet tilpasses efter skærmopløsningen. Fagsystemet skal kunne afvikles i Citrix, såfremt fagsystemet afvikles fra en tyk klient. HTML-koden i selvbetjeningsløsningen skal overholde W3C-standarder, og selvbetjeningsløsningen skal kunne valideres af Selvbetjeningsløsningen skal opfylde retningslinjerne i WCAG 2.0 Level AA, jf. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 37 / 66

38 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_081 Brugervenlighed Teknisk krav MK Formålet er at sikre, at de Selvbetjeningsløsningen skal præsenteres, tilpasses og integreres på digitale selvbetjeningsløsninger borger.dk, og skal overholde den til enhver tid gældende version af kan integreres op mod borger.dk's html-guide: borger.dk NFK_082 Brugervenlighed Teknisk krav X Formålet er at sikre, at selvtjeningsløsningerne inkluderer tællerscripts fra borger.dk NFK_083 NFK_084 NFK_085 Design og applikationsstrukturer Design og applikationsstrukturer Design og applikationsstrukturer Automatiske kørsler X K2 Formålet er at sikre en effektiv drift af systemet Automatiske kørsler X K2 Formålet er at sikre, at ATPs systemer er tilgængelige hele døgnet Automatiske kørsler X K2 Formålet er at sikre fuld kontrol og effektiv gennemførsel af automatiske kørsler. Selvbetjeningsløsningen skal have tællerscripts påsat fra borger.dk og siteimprove, således at antallet af aktiveringer og transaktioner offentliggøres på et skal implementere automatiske kørsler (batchjobs), så batchjobbet fortsætter trods forretningstekniske fejl, såsom manglende adresse, kontonummer el. lign. et skal registrere fejlene, så de kan behandles efterfølgende af kunderådgivere. et skal kunne afvikle automatiske kørsler (batchjobs) og onlinetransaktioner (fx interaktioner med et igennem brugergrænseflader) sideløbende, og samtidigt overholde servicemålene i bilag 7 (Servicemål). Automatiske kørsler må ikke starte forfra ved nedbrud, men skal ved genstart fortsætte hvorfra de nåede. Leverandøren skal tage aktivt stilling til, hvor ofte der skal indsættes genstartspunkt. NFK_086 Design og applikationsstrukturer Automatiske kørsler X K2 Formålet er at undgå fejl, hvis kørselstidspunkter bliver rykket. Leverandøren skal beskrive den valgte løsning af ovenstående i bilag 3B (Løsningsbeskrivelse) et skal designes således, at en proces med flere faser skal identificeres og styres via logiske referencer og ikke udelukkende tidspunkter. Eksempelvis må en automatisk kørsel (batchjob) ikke startes hver dag kl 02:00, hvis den er afhængig af, at andre batchjobs er kørt forinden. NFK_087 NFK_088 Design og applikationsstrukturer Design og applikationsstrukturer Automatiske kørsler X K2 Formålet er at sikre fuld kontrol og effektiv gennemførsel af automatiske kørsler. et skal designes, så det har kontrol over den automatiske kørsel (batchjobbet) under hele batchjobbets reelle køretid og kender dets reelle slutstatus, når alle data er færdigbehandlet. Det betyder, at automatiske kørsler ikke må igangsættes som eksempelvis "fire-and-forget-løsninger" Integrationer MK Formålet er at sikre at ansvaret Løsningens integrationspunkter skal sikre, at data overføres korrekt (dvs. for at håndtere fejl i leveres én gang, er komplet og i korrekt sekvens), samt at der er integrationspunkter er entydigt sporbarhed på tværs af integrationen. Der skal være mulighed for fastlagt, og er robuste, når der gentransmission af al data. opstår en fejlsituation. NFK_089 Design og applikationsstrukturer Integrationer X Formålet er at sikre, at der ikke sendes uvalideret data til backend-services. Hver gang et modtager information via en brugergrænseflade, webservice eller en anden form for ekstern integration, skal informationen valideres ift. format. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 38 / 66

39 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_090 Design og applikationsstrukturer Operationelt design X K2 Formålet er at sikre, at det som testes i testmiljøerne, også virker i produktionsmiljøet. et skal kunne installeres ved hjælp af den samme installationspakke i alle miljøer. Eventuelle miljøafhængige parametre skal kunne konfigureres. NFK_091 NFK_092 NFK_093 NFK_094 Design og applikationsstrukturer Design og applikationsstrukturer Design og applikationsstrukturer Design og applikationsstrukturer Operationelt design X K2 Formålet er at begrænse mængden af aktive data, så et kan opretholde det ønskede performanceniveau jf et skal være designet til at understøtte en effektiv sanering af data og databaser m.v., således at oprydning, arkivering og reorganisering kan ske løbende. Det inkluderer, at midlertidige data slettes, delmængder af data kan arkiveres, og at data kan slettes efter en given periode. bilag 7 (Servicemål), samt sikre, at det er muligt at afstemme på Sanering skal kunne gennemføres uden at påvirke SLA. tværs af historiske, aktuelle og relevante data. Operationelt design X K2 Formålet er at sikre, at Den klientbaserede del af fagsystemet skal understøtte Windows 7 og klientbaseret software kan nyere versioner i både 32 og 64 bit versioner. installeres på ATPs PC-platform. Hvis et anvender browser eller kontorpakke, skal fagsystemet understøtte følgende: Internet Explorer version 10 og nyere versioner samt Microsoft Office 2010 og nyere versioner. Rapportdesign X K2 Formålet er at sikre, at der kan leveres rapporter i et tilpasningsvenlig udtræk. Rapportdesign X K2 Formålet er at sikre, at der kan leveres rapporter på konfigurerbarer udtrækstidspunkter Generelt gælder det, at et ikke skal stille krav til særlige versioner af standardsoftware på klientplatform (eksempler: PCOM, Java, SAPGui og.net) udover hvad der er understøttet idag, jf. bilag 2C (ATP PCb jd l d ) et skal understøtte en udtræksløsning, jf. bilag 3A.6a/Generisk udtræk service Snitfladebeskrivelse, der sikrer, at ATP eller en af denne udpeget administrator, kan vedligeholde eksisterende og definere nye udtræk, uden at dette skal involvere Leverandøren, med mindre data ikke er tilgængelige i informationsmodellen. Dette omfatter ATP's behov for at: Til-/fravælge felter indenfor informationsmodellen Anvende standardfunktioner (tal- og tekstoperatorer mv) på ét eller flere felter Anvende eksisterende konverteringsfunktioner (med eksisterende menes, at de er lavet for ATP i forbindelse med andre udtræk). Udtrækket skal kunne leveres på den fulde bestand eller et subset heraf, og skal leveres i gængse formater (f.eks. CSV, XML osv.) og leveres via gængse kanaler (f.eks. FTP, mail osv.) et skal understøtte at udtræk kan planlægges og automatisk udføres, med angivelse af frekvens for hvornår en rapport bliver udtrukket: Daglig Ugentligt Månedligt Årligt (dato angives uden årstal) Ad hoc (der angives ingen dato, men ATP eller dennes administrator skal kunne iværksætte dette udtræk ved tilvalg evt. som en bestilling, der effektueres). Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 39 / 66

40 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_095 Design og applikationsstrukturer design X K2 Formålet er at sikre, at et kan håndtere ikkefatale fejl. Hvis der opstår prioritet 3 og/eller prioritet 4 fejl, jf. bilag 7 (Servicemål), skal et sikre, at informationer vedrørende fejlen er logget i Leverandørens overvågningsværktøj. et skal derudover korrigeres korrekt for udførte operationer, således at et funktionelt fremstår, som inden den fejlende operation blev forsøgt udført. NFK_096 NFK_097 Design og applikationsstrukturer Design og applikationsstrukturer design X Formålet er, at sikre konsistente data ved kontrolleret nedlukning og genstart. design X Formålet er at sikre dataintegritet ved nedbrud. Som eksempel kan nævnes, at et skal udføre rollback på en databaseopdatering som fejler et skal understøtte en kontrolleret lukning og genstart uden transaktions- og datatab. et skal udføre konsistent rollback i tilfælde af nedbrud og føre et til en tilstand med konsistente data og opsætning, og uden tab af ajourførte dataog accepterede transaktioner. et må ikke miste data, når de er undervejs mellem systemer (i transit), hvis selve systemet eller et af dets nabosystemer bryder ned. NFK_098 Design og applikationsstrukturer design X Formålet er at sikre en effektiv drift og vedligeholdelse. et skal logge resultatet af automatiske kørsler. Logningerne skal dokumentere, hvilke informationer der er benyttet som input og det samlede resultat af afviklingen. Resultatet skal gemmes i indeværende år plus 5 år. Hvorefter det skal slettes. NFK_099 NFK_100 Design og applikationsstrukturer Design og applikationsstrukturer design X K2 Formålet er at sikre, at hele processen er udført korrekt, når den eksekveres i trin design X K2 Formålet er at sikre dataintegritet ved nedbrud Den udtømmende liste af informationer, som logges, defineres i samarbejde med ATP i afklaringsfasen for den relevante Delleverance i Etape II jf bilag 1 (Tidsplan) Processer, der afvikles trinvist, skal inkludere en komplethedskontrol af den fulde proces, f.eks. med antal eller beløb. et skal sikre, at nedbrud i eventuelle automatiske kørsler ikke udløser behov for en generel database restore. NFK_101 NFK_102 NFK_103 Design og applikationsstrukturer Design og applikationsstrukturer Design og applikationsstrukturer design X K2 Formålet er at muliggøre vedligehold og opgraderinger i systemerne. design X K0 Formålet er, at Udbetaling Danmarks ydelsesområder fungerer uafhængigt af hinanden. design X K2 Formålet er at sikre en effektiv drift af systemet. Leverandøren skal tilsikre, at der ikke er behov for at udføre manuel korrektion af data i databasen, køer, i filer eller lignende, inden en automatisk kørsel kan blive genstartet efter et nedbrud Leverandøren skal designe et således, at navngivning af komponenter ikke er begrænsende i forhold til opgradering og vedligehold. Fx må der ikke være hardkodede versionsnavne i applikationer og stinavne. et skal fungere uafhængigt af de øvrige støtte- og fagsystemer hos ATP både i forhold til systemtilgængelighed og performance, jf. bilag 7 (Servicemål). et skal designes og implementeres således, at det, så vidt muligt, fortsætter trods fejl. Fejlene skal logges, og der skal vises sigende fejlmeddelelser til brugeren. NFK_104 Design og applikationsstrukturer design X Formålet er at kunne modificere et efter behov et skal være designet således, at nye kanaler kan blive tilsluttet, hvis et sådant behov opstår. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 40 / 66

41 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_105 Design og applikationsstrukturer design X K2 Formålet er at sikre kontinuerlig afvikling i Driftsmiljøet NFK_106 Hypercare N/A K2 Formålet er at sikre, at Leverandøren etablerer et øget beredskab til at assistere ATP i forbindelse med idriftsættelsen af et. et skal kunne afvikles kontinuerligt døgnet rundt i produktionsmiljøet til trods for tilstedeværelse prioritet 2, 3 eller 4 fejl, jf. bilag 7 (Servicemål). Det betyder eksempelvis, at eksterne systemer, der foretager servicekald i stort omfang, ikke påvirker svartider for servicekald foretaget af andre systemer. Levering af hypercare-ydelse Leverandøren skal fra én måned før og i 3 måneder efter Overtagelsesdagen levere hypercare og support i forbindelse med ibrugtagning af et. Hypercare-ydelsen skal også inkludere hypercare og support i forbindelse med første gang en regelmæssig kørsel igangsætte, f.eks. årskørsler, selv om disse finder sted mere end 3 måneder efter Overtagelsesdagen. Hypercare-ydelsen skal mindst inkludere: Øget beredskab hos Leverandøren Fysisk tilstedeværelse på ATPs lokation i Hillerød af Leverandørens personale, som har et indgående kendskab til og viden om et. Levering af support omkring brug af et til Udbetaling Danmarks øvrige lokationer til ATP's undervisere. NFK_107 Hypercare N/A K2 Formålet er at sikre, at Hotline for ATP's undervisere Leverandøren etablerer et øget Leverandøren skal fra én måned før og i 6 måneder efter beredskab til at assistere ATP i Overtagelsesdagen opretholde en hotline, hvor ATPs undervisere kan forbindelse med idriftsættelsen kontakte Leverandøren via telefon, og instant messaging med af et. spørgsmål vedrørende hensigtsmæssig anvendelse af et, undervisningen af ets øvrige brugere og lignende NFK_108 Hypercare N/A K2 Formålet er at sikre, at Leverandøren etablerer et øget beredskab til at assistere ATP i forbindelse med idriftsættelsen af et. Åbningstider for hotline Leverandørens hotline skal være åben alle Arbejdsdage i tidsrummet 8.00 til 16.00, og Leverandørens besvarelse af henvendelser fra ATPs undervisere skal ske i overensstemmelse med servicemålet for svartid i Leverandørens servicedesk, jf. bilag 7 (Servicemål). NFK_109 Idriftsættelse N/A Formålet med dette krav er at tydeliggøre Leverandørens ansvar ift. planlægning Planlægning af Teknisk Idriftsættelse Leverandøren er ansvarlig for at planlægge idriftsættelsen af et baseret på Leverandørens relevante erfaringer og i overensstemmelse med ATP's krav til idriftsættelsen i bilag 1 (Tidsplan). NFK_110 Idriftsættelse N/A K2 Formålet med kravet er at sikre, at Leverandøren gennemføre idriftsættelsen på en sådan måde, at ATP's forretning forstyrres mindst muligt. Leverandørens plan for idriftsættelse skal som minimum indeholde følgende: Detaljeret drejebog for idriftsættelsen, inklusiv tidspunkt, varighed, afhængigheder og ansvarlig Plan for verifikation af idriftsættelsen Fallback-plan Leverandørens plan for idriftsættelse skal godkendes af ATP. Nedetid ved idriftsættelse Leverandøren skal ved idriftsættelse af et tilsikre, at ATP's forretning og anden drift forstyrres mindst muligt. Leverandøren skal planlægge og gennemføre idriftsættelse således, at den indpasses med ATP's Change Management- og Release Management-processer og tilhørende servicevinduer jf. bilag 2 (Situationsbeskrivelse). Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 41 / 66

42 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_111 Idriftsættelse N/A K2 Formålet med kravet er at sikre at der er særlig opmærksomhed og bemanding omkring førstegangsidriftsættelser og ved førstgangsafvikling af jobs i et. Særligt fokus ved førstegangsidriftsættelser og førstegangsafvikling af jobs Leverandøren skal have et særligt fokus på første gang funktionalitet idriftsættes og første gang jobs i et afvikles. I disse situationer skal Leverandøren samarbejde med ATP for at sikre, at dette forløber succesfuldt, og skal på ATP's anmodning levere øget bemanding, øget kontrol og/eller øget overvågning, herunder give mulighed for at et kan stoppe sager ved hvert step, med henblik på kontrol af funktionalitet. NFK_112 Logning Design X Formålet er at sikre dataintegritet, i forbindelse med konvertering af data. NFK_113 Logning Design X Formålet er at sikre, at ets brug af regler, som benyttes, når der træffes en afgørelse, bliver registreret NFK_114 Logning Design X K2 Formålet er at sikre en hurtig og effektiv forvaltning, og derigennem en høj oppetid. NFK_115 Logning Design X K2 Formålet er at sikre hurtig og effektiv forvaltning. NFK_116 Logning Logdata X Formålet er skabe en ensartet struktur og format for logning af data i et NFK_117 Logning Logdata X Formålet er skabe en ensartet struktur og format for logning af data i et NFK_118 Logning Logdata MK Formålet er skabe en ensartet struktur og format for logning af data i et Leverandøren er ikke berettiget til særskilt vederlag for deltagelse i førstegangsidriftsættelser eller førstegangsafvikling af jobs. et skal sikre, at stamdata og transaktionsdata bliver overført fuldstændigt i forbindelse med konvertering af data. Det betyder, at hvis der er data, som et ikke konverterer, så skal disse opbevares på en sikker måde og med mulighed for adgang til dem i et søgbart format. Der skal kunne skabes en relation mellem nøgler i et og de opbevarede data, som ikke er konverteret. et skal understøtte at brug af regler og begrundelse af regelvalg bliver registreret, med henblik på både fejl- og mønstersøgning, samt til dokumentation af trufne afgørelser. et skal generere fejlbeskeder, som er specifikke og konkrete, samt anviser mulige opfølgningsmønstre. Leverandøren skal i driftsvejledningen for et, jf. bilag 4 (Dokumentation), beskrive overvågningsreaktionen på en given fejlmeddelelse i et, så det er muligt at agere præcist og alene på baggrund af ordlyden i driftsvejledningen et skal sikre en hurtig og effektiv sporing og identificering af fejl. et skal opsamle og gemme logdata via en maskinlæsbar lagringsmetode og gemme disse logdata i et lagringssystem. et skal kunne eksportere logdata i et standardformat, så ATP kan behandle dem i et andet system. Leverandøren skal kunne stille alle audit og revisions logs/rapporter til rådighed for ATP på anfordring. NFK_119 Logning Logdata X Formålet er at sikre, at et kan generere og benytte unikke transaktions ID'er et skal genere og benytte sig af unikke transaktions ID er. Transaktions ID et skal sikre muligheden for at sammenstille logs på tværs af et Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 42 / 66

43 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_120 Logning Logdata MK Formålet er at sikre, at Persondataloven overholdes. Leverandøren skal sikre, at sikkerhedsloggen indeholder oplysninger om anvendelse af fortrolige og følsomme persondata, på nær CPR nr. og indog udbetalingsoplysninger i offentlige ordninger. Loggen skal indeholde oplysning om: - Tidspunkt for anvendelse - Bruger - Type af anvendelse - Angivelse af søgekriterium - Kaldende system. NFK_121 Logning Logdata MK Formål er at kunne spore hvem eller hvad, der har lavet ændringer på et. L k l i 6 å d h ft l tt et skal logge alle parametreændringer med angivelse af: - Hvornår - Af hvem - Hvad der er ændret - Hvornår ændringen gælder fra og til Det skal være muligt at identificere, hvilke parametre, som er anvendt ved gennemførelse af transaktioner, der fører til ændringer i et. NFK_122 Logning Logdata X Formålet er at overholde de uddybende sikkerhedsbestemmelser. NFK_123 Logning Logdata X K2 Formålet er at sikre en effektiv drift af systemet. et skal sikre, at der foretages logning af alt, hvad Privilegerede brugere gør i de dele af et, hvor de er "privilegerede". et skal dokumentere, hvornår en automatisk kørsel (batchjob) starter og slutter, også selvom batchjobbet stopper i utide. Alle batchjobs skal løbende logge deres fremdrift, så deres aktuelle status kan følges. Efterfølgende skal det kunne dokumenteres, hvilke parametre jobbet er kørt på. Endvidere skal det kunne dokumenteres, hvilke parametre der eventuelt er ændret, samt hvem der har udført ændringen. NFK_124 Logning Logdata X Formålet er at muliggøre et skal logge al kommunikation med eksterne parter for at sporing af kommunikation med muliggøre sporing i forbindelse med misbrug og fejlfinding. eksterne parter i forbindelse Det gælder fx browser-adgang, webservices & FTP. med misbrug og fejlfinding. NFK_125 Logning Logdata X Formålet er at kunne udøve effektiv forvaltning. NFK_126 Logning Logdata X Formålet er at kunne udøve effektiv forvaltning. et skal understøtte sporbarhed, så det er muligt at følge hvilke hændelser, der er på en sag. Det skal være muligt at følge relationen i begge retninger, dvs. fra Sag til transaktion og transaktion til sag. et skal kunne håndtere, at en Sag bliver arkiveret. NFK_127 Logning Logtyper X Formålet er, at få et til at implementere generel systemlogning. et skal logge systemhændelser relateret til fx operativsystem, netværk, middleware og applikation(er) for at kunne understøtte effektiv drift og fejlrettelsesaktiviteter. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 43 / 66

44 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_128 Logning Logtyper MK Formålet er at sikre, at Bogføringsloven overholdes. et skal sikre, at der er et transaktionsspor til stede for alle transaktioner, der direkte eller indirekte resulterer i transaktioner og/eller oplysninger til ATP's regnskab. et skal dokumentere, hvordan transaktionssporet er blevet implementeret, herunder hvordan det sikres at transaktionssporet kan føres på tværs af systemer. Log-informationerne gemmes enten sammen med de forretningsmæssige data eller i separate logfiler. NFK_129 Logning Logtyper MK Formålet er at sikre, at Bogføringsloven overholdes. Loggen skal gemmes i indeværende år + 5 år, hvorefter den skal slettes. et skal sikre, at der er et kontrolspor til stede for alle transaktioner. et skal dokumentere definitionen af kontrolsporet. Loggen skal gemmes i indeværende år + 5 år. Hvorefter den skal slettes. Log-informationerne gemmes enten sammen med de forretningsmæssige data eller i separate logfiler. NFK_130 Logning Logtyper MK Formålet er at kunne spore hvem eller hvad, der har lavet ændringer på systemet. et skal sikre, at der er et historikspor på alle ændringer af stam-, posteringsdata og bilagsinformationer. Det skal være muligt at genskabe data pr. en vilkårlig dato. NFK_131 Logning Logtyper MK Formålet er at kunne spore, hvem der har forsøgt at blive autentificeret i et. et skal vedligeholde en adgangskontrollog, når brugerens identitet kontrolleres, jf. Persondataloven NFK_132 Logning Logtyper K2 Formålet er at sikre en hurtig og effektiv forvaltning. NFK_133 Logning Lovgivning MK Formålet er at sikre, at Bogføringsloven overholdes. Leverandøren skal fjerne debug-logninger, som er brugt under test og udvikling, fra alle programmer, inden de løftes i produktion. Leverandøren skal dokumentere logfiler, både i forhold til fil- og informationsstruktur, samt hvordan logdata opsamles og behandles. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 44 / 66

45 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_134 Logning Sikkerhed MK Formålet er at sikre, at integriteten af logfilerne er intakte, samt at informationerne gemmes i den korrekte aftalte periode Leverandøren skal sikre, at ets log-information behandles således, at fortrolighed, autenticitet, integritet og uafviselighed bliver opretholdt, og at Leverandøren kan slette relevante logdata efter de tilhørende dataklassificeringer. NFK_135 Lovgivning N/A MK Formålet er at sikre, at almen lovgivning overholdes NFK_136 Lovgivning N/A MK Formålet er at sikre, at almen lovgivning overholdes efter Overtagelsesdagen ets overholdelse af almen lovgivning et skal designes, udvikles og implementeres på en sådan måde, at alment gældende lovgivning (dvs. Ikke ATP-specifik lovgivning) overholdes, herunder særligt: Arkivloven Bogføringsloven Lov om behandling af personoplysninger(persondataloven) Regnskabsbekendtgørelsen Bekendtgørelsen nr. 528 af 15 juni 2000 om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning (Sikkerhedsbekendtgørelsen) ets fortsatte overholdelse af almen lovgivning efter Overtagelsesdagen Leverandøren skal som en del af Ydelserne vedrørende drift, vedligeholdes og support af et efter Overtagelsesdagen, jf. Kontrakten, sikre den fortsatte overholdelse af følgende lovgivning: Arkivloven Bogføringsloven Lov om behandling af personoplysninger(persondataloven) Regnskabsbekendtgørelsen Bekendtgørelsen nr. 528 af 15 juni 2000 om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning (Sikkerhedsbekendtgørelsen) Den forsatte overholdelse af denne lovgivning er indeholdt i Driftsvederlaget, jf. bilag 5 (Priser og betalingsplan). Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 45 / 66

46 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_137 Lovgivning N/A K2 Formålet er at sikre, at ATPspecifik lovgivning og særlovgivning for offentlige myndigheder overholdes ets overholdelse af ATP-specifik lovgivning Leverandøren skal i hele kontraktperioden medvirke til ets overholdelse af ATP-specifik lovgivning og særlovgivning for offentlige myndigheder, som for eksempel: Lov om en børne- og ungeydelse(børne- og ungeydelsesloven) Lov om børnetilskud og forskudsvis udbetaling af børnebidrag(børnetilskudsloven) Lov om Udbetaling Danmark (Udbetaling Danmark-loven) Forvaltningsloven Lov om offentlighed i forvaltningen (Offentlighedsloven) Lov om retssikkerhed og administration på det sociale område (Retssikkerhedsloven) God forvaltningsskik, jf. udtalelser, afgørelser mv. fra Folketingets ombudsmand NFK_138 Lovgivning N/A Formålet er at sikre, at et understøtter ATPs overholdelse af gældende lovgivning Det påhviler ATP at identificere og foretage de nødvendige fortolkninger af relevante dele af ATP-specifik lovgivning samt omsætte dette til krav til et. Leverandøren skal på ATPs anmodning deltage i dette arbejde efter bedste evne. Ændringer til et håndteres via Kontraktens bestemmelser for Ændringshåndtering og ændringerne skal indarbejdes af Leverandøren uden unødigt ophold, for at sikre rettidig implementering inden ikrafttrædelse af ændret lovgivning. ets understøttelse af ATP's overholdelse af gældende lovgivning et skal designes, udvikles og implementeres på en sådan måde, at et understøtter, at ATP's anvendelse af et er i overensstemmelse med gældende lovgivning, herunder både almen og specifik lovgivning. NFK_139 Miljøer Eksternt testmiljø Formålet er at sikre, at der er det nødvendige eksterne testmiljø til rådighed. NFK_140 Miljøer Eksternt testmiljø Formålet er at sikre, at der er det nødvendige integrationstestmiljø til rådighed. NFK_141 Miljøer Eksternt testmiljø Formålet er at sikre, at der er det nødvendige integrationstestmiljø til rådighed. Etablering af eksternt testmiljø Leverandøren skal etablere et eksternt testmiljø, hvori der kan foretages delleveranceprøver og samlet systemintegrationstest, jf. bilag 6 (Afprøvninger). Det skal i miljøet være muligt at teste konvertering og integrationer separat og uden at testene påvirker hinanden. ATP skal have testadgang til miljøet. Miljøet skal være kørende og tilgængeligt i hele kontraktperioden. Integrationer i eksternt testmiljø I det eksterne testmiljøet skal alle integrationer etableres og testes. Undtaget herfra kan dog være integrationer til brug for autentifikation og autorisation, hvis dette er nødvendigt for at sikre den fornødne adgang med testbrugere. Data i eksternt testmiljø Leverandøren skal sikre, at der kan etableres testdata i det eksterne testmiljø; det skal herunder være muligt både at etablere konstruerede testdata og at indlæse maskerede produktionsdata. Der skal være adgang til et med flere forskellige testbrugere. NFK_142 Miljøer Generelt Formålet er at sikre, at der er Etablering af interne miljøer det nødvendige interne miljø til Leverandøren skal etablere interne miljøer, der dækker Leverandørens rådighed. behov for miljø til udvikling, komponenttest og komponentintegrationstest. Leverandøren er ansvarlig for versions- og releasestyring i de interne miljøer, og det skal være muligt at gennemføre forskellige tests parallelt, således at rækkefølgen for releases ikke nødvendigvis afspejler den rækkefølge de er blevet oprettet i Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 46 / 66

47 Krav ID Kravgruppe Underkrav-gruppe relateret NFK_143 Miljøer Generelt Formålet er at sikre at det er muligt at afprøve al funktionalitet i test- og uddannelsesmiljøerne. NFK_144 Miljøer Generelt K2 Formålet er at sikre, at der findes dokumenterede procedurer for transportering mellem forskellige miljøer. NFK_145 Miljøer Generelt K2 Formålet er at sikre, at der findes dokumenterede procedurer for genopfriskning af transaktionsdata. NFK_146 Miljøer Produktionsmiljø Formålet er at sikre, at der er det nødvendige produktionsmiljø til rådighed. NFK_147 Miljøer Præproduktionsmiljø Formålet er at sikre, at der er det nødvendige præproduktionsmiljø til rådighed. NFK_148 Miljøer Præproduktionsmiljø Formålet er at sikre, at der er det nødvendige præproduktionsmiljø til rådighed. NFK_149 Miljøer Præproduktionsmiljø Formålet er at sikre, at der er det nødvendige præproduktionsmiljø til rådighed. NFK_150 Miljøer Uddannelsesmiljø Formålet er at sikre, at der er det nødvendige uddannelsesmiljø til rådighed. NFK_151 Miljøer Uddannelsesmiljø Formålet er at sikre, at der er det nødvendige uddannelsesmiljø til rådighed. Krav-type Formål med kravet Kravtekst Funktionalitet i test- og uddannelsesmiljøerne I integrationstestmiljøet, præproduktionsmiljøet og uddannelsesmiljøet skal det være muligt at afprøve al ets funktionalitet. Herunder skal det være muligt at simulere et givet tidspunkt, således at tidsbestemt funktionalitet kan afprøves, f.eks. månedskørsler, aldring af sager og lignende Procedure for transportering mellem miljøer Leverandøren skal sikre at der er en klar og kvalitetssikret procedure for transportering af applikationselementer og data mellem de enkelte miljøer og at alle interessenter hos Leverandøren og ATP er gjort bekendt med denne procedure. Procedure for genopfriskning af transaktionsdata Leverandøren skal sikre, at der er en procedure for at genopfriske transaktionsdata (f.eks. prøvekonverterede data) i testmiljøerne, således at en testcase kan gennemføres mere end en gang med de samme test data (f.eks. ved gentest af en rettet fejl). Genopfriskningen af data i testmiljøerne skal udelukkende ske efter aftale med ATP s testmanager og i tæt samspil med testplanen Etablering af produktionsmiljø Leverandøren skal etablere et produktionsmiljø, der opfylder krav til sikkerhed og servicemål, jf. bilag 7 (Servicemål). Etablering af præproduktionsmiljø Leverandøren skal etablere et præproduktionsmiljø, hvori der kan foretages idriftsættelsesprøve, konverteringsprøve og overtagelsesprøve, jf. bilag 6 (Afprøvninger). Miljøet skal være bestykket således, at det er muligt at vurdere performance for det endelige produktionsmiljø. ATP skal have testadgang til miljøet. Miljøet skal være kørende og tilgængeligt i hele kontraktperioden Integrationer i præproduktionsmiljøet I præproduktionsmiljøet skal alle integrationer være etableret (til integrationspartens testmiljøer). Der skal være etableret autentifikation og autorisation af brugere. Data i præproduktionsmiljøet Præproduktionsmiljøet skal kunne håndtere en fuld kopi af produktionsdata, herunder kunne håndtere alle data indkonverteret fra Eksisterende Løsning. Leverandøren skal sikre etablering af mekanismer til indlæsning af data fra produktion Etablering af uddannelsesmiljø Leverandøren skal etablere et uddannelsesmiljø, der afspejler funktionaliteten i produktionsmiljøet, herunder simulering af datoer (så der f.eks. kan simuleres en månedskørsel), simulering af testdata (f.eks. dødsfald) og lignende funktionalitet, hvori der kan foretages undervisning og oplæring. Uddannelsesmiljøet skal være bestykket på en sådan måde, at ATP kan anvende uddannelsesmiljøet uden at opleve svartider der afviger væsentligt fra dem i produktionsmiljøet. Miljøet skal være kørende og tilgængeligt i op til et år efter Idriftsættelse, herefter kan miljøet lukkes ned igen på ATP's anmodning. Integrationer i uddannelsesmiljøet I uddannelsemiljøet skal der være adgang til eksterne integrationer, fx. eindkomst. Hvis det ikke er muligt at etablere reelle integrationer i uddannelsesmiljøet, skal der etableres intelligente stubbe, der kan give et svar som simulerer produktionsmiljøet. Løsningsmåde Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 47 / 66

48 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_152 Miljøer Uddannelsesmiljø Formålet er at sikre, at der er det nødvendige uddannelsesmiljø til rådighed. Data i uddannelsesmiljøet Uddannelsesmiljø skal beriges med et sæt af data, der skal indlæses af Leverandøren før uddannelsessessionens opstart jvf. tidplan i bilag 1 (Tidsplan). Det skal være muligt at konstruere uddannelsesdata (mange CPR-numre med samme navn, sager m.v.) for at sikre en ensartet indlæring og med mulighed for fælles gennemgang. NFK_153 Sikkerhed Data Formålet er at sikre borgerens privatliv, samt at overholde relevant lovgiving, herunder Persondataloven ATP stiller testdata til rådighed for Leverandøren et må ikke indsamle flere informationer end strengt nødvendigt for at kunne gennemføre den pågældende forvaltning. NFK_154 Sikkerhed Data X Formålet er at sikre, at logningskrav til informationer Leverandøren skal sikre, at information er klassificeret på attributniveau i forhold til lognings- og afleveringskrav i: er klare, samt at sletteregler for - Persondataloven information kan specificeres. - Bogføringsloven - Arkivloven NFK_155 Sikkerhed Data X K2 Formålet er at sikre, at der er funktionsadskillelse mellem forretningsfunktioner, udviklingsfunktioner, driftsfunktioner og sikkerhedsfunktioner, således at ingen enkeltperson har eller kan få kontrol over alle faser i IT-anvendelsen - Forvaltningsloven et skal designes således, at driftspersonale og systemforvaltere ikke har behov for skriveadgang i produktionsmiljøet for at kunne udføre den daglige forvaltning. Derudover skal et være indrettet således, at ATP ikke har behov for it-systemadgange for at udføre det daglige arbejde. NFK_156 Sikkerhed Data K2 Formålet er at sikre fuld kontrol over hvem, der laver ændringer i kildekode samt hvilke ændringer, der laves. NFK_157 Sikkerhed Data MK Formålet er at træffe sikkerhedsforanstaltninger ved brug og opbevaring af persondata. NFK_158 Sikkerhed Data MK Formålet er at overholde gældende lovgivning for opbevaring af dokumenter. Leverandøren skal sikre, at adgangen til kildekode og konfigurationsfiler er begrænset i form af adgangskontrol. Kildekoden skal desuden være versionsstyret. Jf. Persondataloven skal Leverandøren alene handle efter instruks fra ATP, i det omfang Leverandøren opbevarer eller på anden vis håndterer persondata ved Kontraktens opfyldelse. Leverandøren skal i den forbindelse træffe tekniske og organisatoriske sikkerhedsforanstaltninger mod, at personoplysninger hændeligt eller ulovligt tilintetgøres, fortabes eller forringes samt mod, at de kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med lov om behandling af personoplysninger. et skal persistere og gemme alle informationer (fx data, dokumenter og logfiler) i den periode, som er krævet i forhold til den fastlagte dataklassifikation. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 48 / 66

49 Krav ID Kravgruppe Underkrav-gruppe relateret NFK_159 Sikkerhed Design X Formålet er at sikre, at brugeren bliver autoriseret. NFK_160 Sikkerhed Design X Formålet er at sikre at der ikke kan foregå manipulering gennem URL NFK_161 Sikkerhed Design X Data som transmitteres over åbne linjer skal sikres med stærk kryptering NFK_162 Sikkerhed Design X Formålet er at sikre, at der er funktionsadskillelse mellem forretningsfunktioner, udviklingsfunktioner, driftsfunktioner og sikkerhedsfunktioner, således at ingen enkeltperson har eller kan få kontrol over alle faser i IT-anvendelsen NFK_163 Sikkerhed Design X K2 Formålet er at sikre korrekte data. Krav-type Formål med kravet Kravtekst NFK_164 Sikkerhed Design X K2 Formålet er, at der ikke må gives flere rettigheder til brugerne, end der er behov for at løse opgaven. NFK_165 Sikkerhed Design X K2 Formålet er at sikre, at eksterne personer eller systemer ikke får unødig information, der potentielt kan benyttes til at finde sikkerhedshuller. NFK_166 Sikkerhed Informationssikkerhedspo litik X Formålet er at overholde informationssikkerhedspolitikk en og de uddybende sikkerhedsbestemmelser et skal sikre, at brugere autoriseres i forhold til de data og den funktionalitet, som brugeren har rettigheder til, jf. ATPs informationssikkerhedspolitik, bilag 13A (Politik for Informationssikkerhed). et skal være konstrueret således, at selvbetjeningsløsningen ikke kan manipuleres gennem manuel retning i URL. et skal være konstrueret således, at data, som transmitteres over åbne linjer, er sikret med stærk kryptering. Stærk kryptering defineres som min. 128 bit kryptering (symmetrisk) med AES algoritmen. Det skal ske for at beskytte fortroligheden af data, samtidig med at der opnås vished for, at data ikke har undergået forvanskning under transporten. et skal være konstrueret således, at der findes behørig funktionsadskillelse i et, hvor der er risiko for svig, eller hvor funktionen har høj forretningsrisiko, dvs. at det sikres, at samme person ikke alene kan: - Initiere - Udføre - Godkende. Som eksempel på hvor i systemet dette skal være, nævnes, når der udføres opgaver, der involverer udbetaling af penge. et skal sikre, at alle dataoperationer i relationelle databasesystemer fortages på en sikker måde. En nærmere beskrivelse af, hvordan databaseadgange fortages, skal beskrives i dokumentationen, jf. bilag 4 (Dokumentation). et skal være designet efter least privilege princippet. Det betyder, at brugere ikke må tildeles flere rettigheder, end der er behov for at løse opgaven. ets fejlbeskeder skal parametriseres og kunne tilpasses på samme vis som øvrige tekster i brugerfladen. Det skal sikres, at brugeren altid modtager meningsfulde fejlbeskeder uden unødige tekniske detaljer, som ville være uvedkommende for brugeren eller ville kunne kompromittere ets sikkerhed ved at afsløre detaljer om ets interne virkemåde. et skal logge den detaljerede beskrivelse af fejlen i fejlloggen. et skal sikre autenticitet i forbindelse med behandling af data og itsystemer. Kun når betingelserne om autenticitet, integritet og uafviselighed for en given information er, kan der disponeres i tillid til informationen. Løsningsmåde NFK_167 Sikkerhed Informationssikkerhedspo litik X Formålet er at overholde informationssikkerhedspolitikk en og de uddybende sikkerhedsbestemmelser et skal sikre integritet i forbindelse med behandling af data og itsystemer. Kun når betingelserne om autenticitet, integritet og uafviselighed for en given information er, kan der disponeres i tillid til informationen. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 49 / 66

50 Krav ID Kravgruppe Underkrav-gruppe relateret NFK_168 Sikkerhed Informationssikkerhedspo litik Krav-type Formål med kravet Kravtekst X Formålet er at overholde informationssikkerhedspolitikk en og de uddybende sikkerhedsbestemmelser et skal sikre uafviselighed i forbindelse med behandling af data og itsystemer. Kun når betingelserne om autenticitet, integritet og uafviselighed for en given information er, kan der disponeres i tillid til informationen. Løsningsmåde NFK_169 Sikkerhed Informationssikkerhedspo litik Formålet er at overholde informationssikkerhedspolitikk en og de uddybende sikkerhedsbestemmelser et skal sikre, at ordninger kun benytter data, - som ordningen selv ejer, - hvor der er lavet aftale om at hente disse fra 3. part systemer - som er offentligt tilgængelige. NFK_170 Sikkerhed Informationssikkerhedspo litik X Formålet er at overholde informationssikkerhedspolitikk en og de uddybende sikkerhedsbestemmelser Det er ikke tilladt at benytte data fra andre myndighed/kilder med mindre det er specifikt nævnt i lovgivningen, jf. ATP's informationssikkerhedspolitikk, bilag 13A (Politik for Informationssikkerhed) et skal foretage en registrering af alle gennemførte og afviste adgangsforsøg. Hvis der, indenfor en fastsat periode, er registreret et nærmere fastsat antal på hinanden følgende afviste adgangsforsøg fra samme arbejdsstation, server eller med samme brugeridentifikation, så skal et blokere for yderligere forsøg i en nærmere fastsat tidsperiode. NFK_171 Sikkerhed Informationssikkerhedspo litik NFK_172 Sikkerhed Informationssikkerhedspo litik NFK_173 Sikkerhed Informationssikkerhedspo litik X Formålet er at overholde informationssikkerhedspolitikk en og de uddybende sikkerhedsbestemmelser Formålet er at revidere de Privilegerede brugere adgange. X Formålet er at overholde informationssikkerhedspolitikk en og de uddybende sikkerhedsbestemmelser NFK_174 fleksibilitet Flytbarhed X K2 Formålet er at sikre, at et er flytbart i forhold til Driftsmiljøet NFK_175 fleksibilitet Flytbarhed X K2 Formålet er at sikre en effektiv og dynamisk drift af et, samt at sikkerhedsfølsomme informationer ikke er frit tilgængelige. Denne tidsperiode skal kunne konfigureres et skal leve op til ATPs informationssikkerhedspolitik og de uddybende retningslinjer i Sikkerhedshåndbogen, jf. hhv. bilag 13A (Politik for Informationssikkerhed) og bilag 13B (Sikkerhedshåndbogen). ATP Sikkerhedsfunktion skal 2 gange årlig godkende og revidere Leverandørens Privilegerede brugere og de tilknytte roller. Leverandøren skal på forlangen dokumentere nødvendigheden af rollernes adgange og brugerne stadigvæk er aktive/nødvendige. Leverandøren skal implementere forebyggende kontrolforanstaltninger med henblik på at minimere risikoen for besvigelse og/eller datamisbrug. et skal kunne installeres på og porteres til forskellige driftsmiljøer, såfremt driftsmiljøerne opfylder ets krav hertil. Leverandøren skal sikre, at koden ikke indeholder hardkodede parametre. Det gælder for tekniske parametre som fx brugernavne, passwords og IP numre. Det gælder også for forretningsmæssige parametre, som fx satser, alder og lignende. Disse konstanter skal læses fra konfigurationsfiler eller databaser for online applikationer, som samtidigt er sikret, så informationen ikke er frit tilgængelig. NFK_176 fleksibilitet Flytbarhed X K2 Formålet er at sikre at brugergrænseflader er modulopbyggede, så effektiv udvikling og drift sikres. Modulopbygget brugergrænseflader et skal indeholde modulopbyggede brugergrænseflader som skal kunne sammensættes på tværs af et, uden det skal omkodes. Tilbudsgiver skal i sin besvarelse af tilbuddet redegøre for hvordan brugergrænsefladerne for brugerne bygges op i moduler, således at moduler frit kan tages og sammensættes af andre eller nye moduler. Eksempler herpå kunne være moduler der skulle slås fra i forhold til en Posthåndteringsleverandør får adgang til et eller der skal tilføjes et nyt modul i forbindelse med der bliver oprettet en ny rolle til varetagelse af nogle specifikke arbejdsgange. Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 50 / 66

51 Krav ID Kravgruppe Underkrav-gruppe relateret NFK_177 fleksibilitet Vedligeholdelse X Formålet er at kunne modificere et efter behov Krav-type Formål med kravet Kravtekst Leverandøren skal sikre, at et er fleksibelt opbygget, således at det kan modificeres med hensyn til design og funktionalitet i takt med, at efterspørgsel og behov ændres i ets livscyklus. NFK_178 fleksibilitet Vedligeholdelse X Formålet er at sikre, at et kan vedligeholdes og videreudvikles løbende uden Leverandøren skal sikre, at et kan videreudvikles og vedligeholdes løbende, uden uforholdsmæssigt store omkostninger for ATP. ets design og struktur skal understøtte dette, og skal tillade at rettelser og for store omkostninger for ATP. tilpasninger kan gennemføres, uden at hele et skal NFK_179 Test Datasikkerhed X Formålet er at sikre, at Persondataloven overholdes i forbindelse med test. NFK_180 Test Datasikkerhed X Formålet er at sikre, at Persondataloven overholdes i forbindelse med test. NFK_181 Test Datasikkerhed X Formålet er at sikre, at Persondataloven overholdes i forbindelse med test. NFK_182 Test Datasikkerhed X Formålet er at sikre, at Persondataloven overholdes i forbindelse med test. NFK_183 Test Datasikkerhed X Formålet er at sikre, at Persondataloven overholdes i forbindelse med test. genimplementeres Ved anvendelse af umaskerede produktionsdata til testformål skal Leverandøren sikre, at data kun behandles i miljøer/systemer, som er underlagt sikkerhedsbekendtgørelsens retningslinjer, herunder om lognings-krav, samt er konstrueret, så det er målrettet en test, som er egnet i forhold til det relevante produktionsmiljø. Ved anvendelse af umaskerede produktionsdata til testformål skal Leverandøren sikre, at data kun behandles af personer hos Leverandøren eller eventuelle underleverandører, der efter Overtagelse, vil være beskæftiget med opgaver, der kan begrunde autorisation til at behandle data. Ved anvendelse af umaskerede produktionsdata til testformål skal Leverandøren føre oversigt over hvilke personer hos Leverandøren eller eventuelle underleverandører, som har deltaget i hvilke tests og prøver, med angivelse af hvilke funktioner og hvilke typer af data, de enkelte personer har haft adgang til Ved anvendelse af produktionsdata til testformål skal Leverandøren sikre, at der ikke behandles flere data end nødvendigt. Leverandøren skal forelægge beslutningen om, hvor stor en andel af produktionsdataene, der skal benyttes til løsning af den konkrete opgave for ATP til godkendelse. Ved anvendelse af produktionsdata til testformål skal Leverandøren løbende vurdere, om testens formål kan opfyldes med helt eller delvist maskerede/anonymiserede data, samt udføre den nødvendige maskering/anonymisering. ATP bistår i det omfang ATP finder det nødvendigt ved vurderingen af, hvilket niveau af anonymisering/maskering der er nødvendigt og proportionalt i det konkrete tilfælde, for at testen fortsat kan udføres fyldestgørende. NFK_184 Tilgængelighed Operationelt design Formålet er at sikre, at 3. parts Leverandøren skal sikre at 3.parts indhold ikke indfluerer på indhold på websider ikke brugeroplevelsen. indfluerer på brugeroplevelsen. NFK_185 Tilgængelighed Operationelt design Formålet er at undgå unødvendige servicevinduer, ud over servicevinduer, der er aftalt for det pågældende ift. vedligehold. NFK_186 Uddannelse N/A K0 Formålet er at sikre, at den nødvendige uddannelse gennemføres, så ATPs projektteam kan deltage effektivt i projektet et skal have en høj robusthed mod nedbrud, så ikke-planlagte servicevinduer undgås. et skal kunne fortsætte normal drift efter at have logget informationer om den opståede fejl. Uddannelse af ATPs projektteam Leverandøren skal sikre den nødvendige uddannelse af ATPs projektteam på leverandør-, løsnings- og metodespecifikke områder. Uddannelsen skal gøre ATPs projektteam i stand til at deltage effektivt i projektet omkring design, udvikling og ibrugtagning af et. Løsningsmåde NFK_187 Uddannelse N/A K0 Formålet er at sikre, at den nødvendige uddannelse gennemføres, så ATP kan ibrugtage et. Uddannelse af ATPs undervisere Leverandøren skal sikre den nødvendige uddannelse af ATPs udvalgte medarbejdere, der er ansvarlige for undervisningen af ets øvrige brugere ( train the trainer ). Uddannelsen skal gøre ATPs undervisere i stand til at gennemføre uddannelsen af de øvrige brugere af et Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 51 / 66

52 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_188 Uddannelse N/A K0 Formålet er at sikre, at den nødvendige uddannelse gennemføres, så ATP kan ibrugtage et. NFK_189 Uddannelse N/A K2 Formålet er at sikre, at den nødvendige uddannelse gennemføres, så ATP kan ibrugtage et. Uddannelse af ATPs forretningsadministratorer Leverandøren skal sikre den nødvendige uddannelse af ATPs forretningsadministratorer, der er ansvarlige for den daglige konfigurering og opsætning af et. Tidsrammer for uddannelse Leverandøren skal sikre, at gennemførelsen af uddannelse sker umiddelbart før ATPs medarbejdere har behov for kompetencerne. Endvidere skal Leverandøren sikre, at uddannelsen af ATPs undervisere sker i tilstrækkelig tid til at ATPs undervisere kan nå at gennemføre uddannelsen af de øvrige brugere af et inden idriftsættelsen af et. Tidsmæssig placering og varighed af Leverandørens uddannelse fremgår af bilag 1 (Tidsplan). NFK_190 Uddannelse N/A K2 Formålet er at sikre, at den nødvendige uddannelse gennemføres, så ATP kan ibrugtage et. NFK_191 Uddannelse N/A K2 Formålet er at sikre, at det nødvendige uddannelsesmateriale etableres, så ATP kan ibrugtage et. Planlægning af uddannelse Leverandøren skal sikre, at den samme uddannelse gennemføres ved flere sessioner, placeret på forskellige dage og på forskellige tidspunkter af dagen. Dette skal give ATPs medarbejdere mulighed for at deltage i undervisning på det tidspunkt, der bedst passer ind i den enkelte medarbejders øvrige arbejde. Omfanget af ATPs medvirken i forbindelse med deltagelsen i Leverandørens undervisning fremgår af bilag 9 (ATP's medvirken) Udarbejdelse af eget undervisningsmateriale Leverandøren er ansvarlig for udarbejdelsen af alt undervisningsmateriale, som nødvendig for Leverandørens undervisning af ATP. Undervisningsmaterialet skal i forbindelsen med undervisningen - dog senest 3 måneder før Overtagelsesdagen, jf. bilag 1 (Tidsplan) - gøres elektronisk tilgængeligt for ATP i et for ATP læsbart og redigerbart format. Undervisningsmaterialet til ATP's forretningsadministratorer kan - såfremt et basere sig på Standardprogrammel - bestå af eksisterende materiale for Standardprogrammelet med nødvendige tilpasninger og kan være på enten dansk eller engelsk. NFK_192 Uddannelse N/A K2 Formålet er at sikre, at Leverandøren på ATP's anmodning kan bistå med udarbejdelsen af det undervisningsmateriale, som ATP's undervisere skal bruge til uddannelsen af ets brugere. NFK_193 Uddannelse N/A K2 Formålet er at sikre, at den nødvendige uddannelse gennemføres, så ATP kan ibrugtage et. Udarbejdelse af undervisningsmateriale til brug af ATP's undervisere Leverandøren skal på ATP's anmodning bistå med udarbejdelsen af det uddannelsesmateriale, som ATP's undervisere skal anvende til ATP's undervisning af de øvrige brugere af et. Bistand til udarbejdelsen af dette undervisningsmateriale er IKKE indeholdt i Leverancevederlaget, men afregnes særskilt som timebaserede ydelser, jf. bilag 5 (Priser og betalingsplan). Leverandørens deltagelse i ATP's undervisning af ets brugere Leverandøren skal deltage som observatør og sparingspartner ved første session af ATP's undervisning af ets brugere. I forbindelse med undervisningen skal Leverandøren levere sparing til ATP's underviser, såfremt dette er nødvendigt for en succesfuld gennemførelse af sessionen. Endvidere skal Leverandøren efter sessionens afslutning levere mundtlig og skriftlig feedback til ATP's undervisere omkring eventuelle optimeringer af ATP's undervisning Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 52 / 66

53 Krav ID Kravgruppe Underkrav-gruppe relateret Krav-type Formål med kravet Kravtekst Løsningsmåde NFK_194 Uddannelse N/A K2 Formålet er at sikre, at den nødvendige uddannelse gennemføres, så ATP kan ibrugtage et. Supplerende uddannelse af ATP's undervisere Leverandøren skal tilbyde supplerende uddannelse af ATP's udvalgte medarbejdere, der er ansvarlige for undervisningen af ets øvrige brugere ( train the trainer ). Den supplerende uddannelse skal afholdes 3-6 måneder efter den oprindelige uddannelse af ATP's undervisere, og skal indeholde en genopfriskning af væsentlige områder fra den oprindelige uddannelse, samt udviddet undervisning områder af særlig relevans med henblik på at fremme en effektiv anvendelse af et. Supplerende uddannelse af ATP's undervisere er IKKE indeholdt i Leverancevederlaget, men afregnes særskilt som timebaserede ydelser, jf. bilag 5 (Priser og betalingsplan). Non.funkt. krav Bilag 03A.1 - Kravliste.xlsx Side 53 / 66

54 Krav til Ydelserne Krav ID Kravgruppe Krav-type Kravtekst YDL_001 Change management K2 Leverandøren skal altid rejse ændringsanmodninger, jf. Change Management-processen, ved ønske om tiltag til forbedring eller fastholdelse af tilgængelighed af Driftsmiljøet. YDL_002 Change management K2 Leverandøren må ikke som udgangspunkt foretage ændringer i den anvendte hardware, hvis dette betyder, at ATP s udgifter til Programmel stiger. I sådanne tilfælde skal ATP s forudgående skriftlige accept foreligge YDL_003 Change management Leverandøren skal oprette en Request for Change (RfC) for løsning af Incidents, som vedrører Driftsmiljøet. Disse RfC skal behandles i henhold til Change Management-processen. YDL_004 Change management K2 Leverandøren skal informere ATP om behovet for RfC i forbindelse med problemløsning, hvor dette er nødvendigt - og tillige oprette disse. Disse RfC skal behandles i henhold til Change Management-processen. YDL_005 Change management K2 Alle Changes skal klassificeres og tilknyttes relevant område efter nærmere aftale mellem Leverandøren og ATP. Bekræftelsen for modtaget RfC indeholder RfC ID hos Leverandøren, samt hvilken afdeling hos Leverandøren, som behandler RfC'en. ATP skal ligeledes have mulighed for at tilgå relevante personer hos Leverandør i forbindelse med normal afklaring og analyse i forhold til udarbejdelse af RfC er. Nærmere processer aftales i forbindelse med Leverandørens udarbejdelse YDL_006 Change management K2 Leverandøren skal oprette RfC er for at modvirke Incidents/Problems og optimere et og Driftsmiljøet. Disse RfC er skal følge Change Management processen. YDL_007 Change management Leverandøren skal implementere alle godkendte Changes, der falder inden for Leverandørens ansvar indenfor de af ATP fastsatte servicevinduer og tidsfrister jf. bilag 2 (Situationsbeskrivelse) og bilag 7 (Servicemål). YDL_008 Change management K2 Leverandøren kan alene opnå særskilt vederlag for udførelse af en Change, såfremt Changen ikke er omfattet af Leverandørens ydelser der vederlægges via Driftsvederlaget, jævnfør bilag 5 (Priser og b t li l ) Leverandøren skal, i samarbejde med ATP, udarbejde og vedligeholde en liste af standard-changes for ydelsesområdet. Ved periodiske møder med ATP vedtages eventuelle Standard Changes, som ATP godkender. Standard Changes forventes i udgangspunktet gennemført inden for 48 timer. Standard-Changes skal fremgå af Driftsaftalehåndbogen. Leverandøren kan alene opnå betaling for udførelse af en Standard Change, såfremt Changen ikke er omfattet af Leverandørens faste ydelser. Et eventuelt vederlag for udførelse af Standard Changes skal aftales med ATP. Leverandørens besvarelse YDL_009 Change management Konfigurationsændringer foretaget af forretningsadministratorer foretages som Standard Changes på positivlisten jf. YDL_008 og følger Change processen. Ændringer transporteres gennem miljøer jf. NFK_123. YDL_010 Change management Changes må kun udføres af Leverandøren efter godkendelse fra ATP i henhold til Change Management-processen. YDL_011 Change management K2 ATP forbeholder sig retten til at holde en Change åben i op til 72 timer efter implementering. Før en Change kan lukkes, skal den være dokumenteret og godkendt. Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 54 / 66

55 Krav ID Kravgruppe Krav-type Kravtekst YDL_012 Change management K2 Ved oprettelsen af en Change, skal følgende beskrives: Projektplan, inkl. tidsplan, aktivitetsplan, milepæle, forventet timeforbrug fordelt på ressourcekategorier Testplan Fallback-plan, såfremt ATP måtte ønske dette Konsekvenserne af Changen for et, herunder eventuelle konsekvenser for servicemålene, jf. bilag 7 (Servicemål) Økonomiske konsekvenser af Changen, inkl. eventuelle afledte, økonomiske konsekvenser ATP s eventuelle medvirken Impact for Change vurderes Low, Medium eller High Det konkrete format for Changes aftales i forbindelse med udarbejdelse af Driftsaftalehåndbogen, hvor templates herfor fastlægges. YDL_013 Change management K2 Leverandøren skal indmelde Changes til servicevinduer som beskrevet i bilag 2 (Situationsbeskrivelse). YDL_014 Change management K2 Leverandøren skal sikre, at der ved implementeringen af Changes eller som følge af driftsmæssige forhold ikke sker forringelser af svartiderne, jf. bilag 7 (Servicemål), med mindre ATP har accepteret en sådan forringelse i forbindelse med godkendelsen af Changen. YDL_015 Dokumentation og konfigurationsstyring Alle systemmæssige ændringer i opsætningen af Driftsmiljøet skal som udgangspunkt være dokumenterede i Configuration Management database (CMDB) og stilles til rådighed for ATP og dennes revision. YDL_016 Dokumentation og konfigurationsstyring K2 Leverandøren skal have en dokumenteret proces for patchning af et. Denne proces skal være underlagt Change Managementprocessen. Leverandøren skal anvende et Configuration Management databasesystem (CMDB-system), der skal indeholde ajourført information om Driftsmiljøet. YDL_017 Dokumentation og konfigurationsstyring K2 Alle konfigurationselementer skal være sporbare i Configuration Management databasen. Det skal således være muligt at følge historik på et konfigurationselement. YDL_018 Dokumentation og konfigurationsstyring K2 Som eksempler på elementer, der skal fremgå af CMDB, kan følgende nævnes: Hardware- og softwarekomponenter i Driftsmiljøet Sammenhænge mellem konfigurationselementer Udarbejdelse og vedligehold af specifikke driftsinstrukser på de områder, som Leverandøren har ansvaret for. Versionering af installerede applikationer Serviceniveau, fx SLA + tidspunkt for fejlmelding Leverandøren skal stille den til enhver tid opdaterede CMDB til rådighed for ATP på et fælles netsted i et for ATP læsbart og godkendt format. Den samlede CMDB skal ved kontraktophør udleveres til ATP. Leverandøren må ikke dele ATP s CMDB med andre kunder. Leverandøren skal opdatere CMDB samt øvrig dokumentation for Driftsmiljøet ved enhver ændring, så det til enhver tid afspejler Driftsmiljøet. Leverandørens processer og driftsdokumentation skal være af en sådan standard, at den lever op til ITIL 3 Leverandøren er forpligtet til at sikre, at der altid findes opdateret Dokumentation over hvilket Programmel, det vil sige samtlige programmeltyper omfattet af Kontrakten, der er installeret på maskinellet Leverandøren skal udstille CI's, således at der demonstreres konfigurationsstyring af kildekode. I samarbejde med ATP defineres passende niveau, således at der kan laves baselines mod integrationer til ATP s Øvrige Leverandører. CI's skal være på et sådant niveau, at de kan bruges til at afdække, hvad der eventuel påvirkes af fremtidige Releases. YDL_019 YDL_020 YDL_021 YDL_022 Dokumentation og konfigurationsstyring Dokumentation og konfigurationsstyring Dokumentation og konfigurationsstyring Dokumentation og konfigurationsstyring K2 K2 K2 Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 55 / 66

56 Krav ID Kravgruppe Krav-type Kravtekst YDL_023 Etablering af kommunikationsinfrastruktur Leverandøren skal etablere og påtage sig driftsansvaret for den nødvendige kommunikationsinfrastruktur mellem ATP og adresser for maskinellets placering. YDL_024 Etablering af kommunikationsinfrastruktur K2 Kommunikationsinfrastrukturen skal fra etableringstidspunktet og i resten af Kontraktens løbetid dimensioneres således at det sikres, at Servicemålene i bilag 7 (Servicemål) overholdes Leverandøren skal etablere forbindelser der sikrer, at kommunikation til tredjeparter og kommunikation mellem ATP s applikationer, jævnfør bilag 2 (Situationsbeskrivelse), kan udføres. YDL_025 Etableringsydelsen Leverandøren skal etablere et samlet Driftsmiljø, der i sin helhed og i enkeltdele har tilstrækkelig kapacitet til at opfylde de opstillede Servicemål, jf. bilag 7 (Servicemål) og de sikkerhedsmæssige krav i bilag 13 (Sikkerhed) YDL_026 Etableringsydelsen Leverandøren skal i samarbejde med ATP udarbejde en Driftsaftalehåndbog for et og Driftsmiljøet. De nærmere krav til indholdet fremgår af bilag 4 (Dokumentation). YDL_027 Event management - overvågning YDL_028 Event management - overvågning Det er Leverandørens ansvar at udarbejde og vedligeholde Driftsaftalehåndbogen Leverandøren skal levere 24-7-overvågning for Driftsmiljøet, således at alle driftsforstyrrelser, herunder potentielle driftsforstyrrelser, udløser alarm og fejlmeldes. Alle hændelser, der potentielt kan medføre at Servicemålene jævnfør bilag 7 (Servicemål) overskrides skal udløse alarmer I det tilfælde hvor overvågningen ikke kan foretages automatiseret, skal den foretages manuelt. YDL_029 Event management - overvågning YDL_030 Event management - overvågning YDL_031 Event management - overvågning YDL_032 Event management - overvågning K2 I fald der aktiveres alarmer mv., der kræver umiddelbar reaktion fra Leverandøren, skal disse tiltag iværksættes umiddelbart, således at driftsforstyrrelser kan reduceres. De faktiske tiltag skal fra Leverandørens side dokumenteres som Changes/Incidents, jf. Incident og Change processerne og tilhørende Servicemål, jf. bilag 7 (Servicemål). Leverandøren skal tilpasse sit overvågningsmiljø, når infrastruktur og/eller forretningsapplikationer ændres og derved påvirker aftalte overvågningstransaktioner. Disse tilpasninger skal gennemføres samtidig med, at Changes gennemføres i Driftsmiljøet ATP skal have læseadgang til Leverandørens aktive overvågningsplatform i real time, således ATP løbende kan monitorere status over samtlige overvågede komponenter, herunder i særligt grad i forhold til de i bilag 7 (Servicemål) specificerede Servicemål. Leverandøren skal levere et business view til ATP's overvågningsmiljø. Det vil sige, at Leverandøren skal levere en beskrivelse af forretningstransaktioner, således at transaktionerne kan blive optaget i ATP's produkt til overvågning af business view, HP Business Service Management (BSM). I Etape I, jf. bilag 1 (Tidsplan), skal Leverandøren aftale med ATP, hvilke konkrete forretningstransaktioner, der skal indgå i business viewet. ATP forventer, at mellem 10 og 20 forretningstransaktioner skal indgå i business viewet. Eksempel på forretningstransaktioner kunne være "Vis personoverblik". YDL_033 Incident management Leverandørens servicedesk skal sikre, at alle henvendelser registreres, behandles og logges i Leverandørens ITSM system. Leverandøren skal ligeledes sikre, at status ajourføres i ITSM systemet, og at ATP løbende orienteres, når status opdateres i overensstemmelse med Servicemålene i bilag 7 (Servicemål) Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 56 / 66

57 Krav ID Kravgruppe Krav-type Kravtekst YDL_034 Incident management K2 Leverandøren skal gennem registreringer i Leverandørens ITSM-system sikre, at flest mulige henvendelser bliver løst ved første kontakt. For at sikre dette, skal Leverandøren vedligeholde FAQ-lister og løsninger på tilbagevendende Incidents i ITSM systemet. Tilgrundliggende årsager, root cause, skal således identificeres hurtigt og registreres som kendte fejl. YDL_035 Incident management K2 Leverandøren skal anvende de i bilag 7 (Servicemål) angivne kategorier ved prioritering af Incidents. YDL_036 Incident management ATP kan altid omprioritere et Incident. Såfremt Leverandøren er uenig i ATP s prioritering, er det til hver en tid ATP s prioritering, der er den gældende. YDL_037 Incident management K2 Leverandøren skal eskalere alle Incidents, som ikke endeligt kan afhjælpes, til Problem Management ved at oprette sagen som et problem. YDL_038 Incident management Leverandøren skal tilbyde et dedikeret telefonnummer til eskalation i tilfælde af prioritet 1 incidents, som eskaleres udenfor Leverandørens servicedesk s åbningstid. YDL_039 Incident management K2 Leverandøren skal løbende foretage en opfølgning på processen for håndtering af Incidents for at sikre erfaringsopsamling, der kan forbedre Incident Management processen. YDL_040 Løbende drift Leverandøren skal sikre, at alle de licenser, der indgår i Leverancen, er fyldestgørende i forhold til ATP s aftalte brug af et, og at disse licenser vedligeholdes i hele kontraktperioden. YDL_041 YDL_042 Løbende drift Løbende drift K2 Certifikater, som Leverandøren er ansvarlig for, skal løbende vedligeholdes af Leverandøren. Det påhviler Leverandøren at sikre, at certifikater er opdateret rettidigt og under hensyntagen til gældende servicevinduer og Change Management-processen. Certifikater, som ATP er ansvarlig for, skal overvåges på samme måde som Leverandørens certifikater, og Leverandøren skal underrette ATP om udløb mv. senest 60 dage før udløb. Processen for underretning af ATP ft l i D fit ft l hå db ATP skal - fra ATP s lokation og netværk - have realtids læseadgang til samtlige miljøer omfattet af Kontrakten. Læseadgang til samtlige miljøer omfattet af Kontrakten omfatter læseadgang til systeminformationer såsom eksempelvis logs og performancetal YDL_043 Løbende drift K2 En oversigt over ressourceberedskab indarbejdes i Driftsaftalehåndbogen og ajourføres mindst en gang årligt. YDL_044 Løbende drift Leverandøren har det fulde ansvar for at tilkalde eventuelle underleverandører/3. partsleverandører, hvis der er behov for tilkald i forbindelse med adresseringen af et Incident. Leverandøren skal selv afholde udgifter til eventuelle serviceaftaler og udfører de nødvendige foranstaltninger under hensyntagen til Servicemålene i bilag 7 (Servicemål) YDL_045 Løbende drift K2 Leverandøren skal sikre, at de forretningsapplikationer, som skal afvikles på PC-platformen, tilpasses og vedligeholdes i overensstemmelse med seneste 2 versioner af den basis-software, som indgår i ATP's PC-platform jf bilag 2C (ATP PC arbejdsplads ) YDL_046 Løbende drift K2 Såfremt et kræver installation på klientmaskiner, skal dette software leveres som én samlet installation baseret på MSI (Windows Installer) pakkeformat. YDL_047 Løbende drift K2 MSI-pakkerne skal være tilgængelige for ATP. Procedurer for håndtering af MSI-pakker aftales i forbindelse med udarbejdelse og godkendelse af Driftsaftalehåndbogen YDL_048 Løbende drift K2 ATP skal have læseadgang til Leverandørens batchscheduleringssystem til brug for eksempelvis opfølgning på incident og problem håndtering. YDL_049 Løbende drift Batchjobs skal kunne scheduleres og afvikles for sammenhængende applikationer på forskellige platforme gennem ét tværgående standardværktøj, således at afhængigheder mellem f.eks. Nemkonto data og Beriget Grunddata til en udbetalingskørsel styres via scheduleringsværktøjet. Alle batchjobs skal være kalenderlagte og kategoriseret ud fra kriterierne i bilag 7 (Servicemål). Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 57 / 66

58 Krav ID Kravgruppe Krav-type Kravtekst YDL_050 Løbende drift K2 Leverandøren skal på ATP s anmodning og mod særskilt betaling levere timebaserede ydelser for at muliggøre et ekstraordinært vagtberedskab, jf. bilag 5 (Priser og betalingsplan). Detaljer for vagtberedskabet aftales under udarbejdelse af Driftsaftalehåndbogen YDL_051 Løbende drift K2 Der skal rapporteres på kritiske batchkørsler som følger: Kategori A: Leverandøren skal på hverdage inden kl levere en rapport med status for kørselsafvikling på fælles site. Ved forsinkelse og/eller nedbrud skal der rapporteres hver time indtil afvikling er afsluttet korrekt. Alle nedbrud (og forsinkelser, der ikke indhentes inden deadline) skal håndteres som Major Incidents (prioritet 1), og Leverandøren skal levere en redegørelse om nedbrud jf. krav om redegørelse ved Major Incident. Kategori B: Leverandøren skal på hverdage inden kl levere en rapport med status for kørselsafvikling på fælles site. Ved forsinkelse og/eller nedbrud skal der rapporteres hver time indtil afvikling er afsluttet korrekt. Nedbrud skal håndteres som Incidents prioritet 2 (eller efter aftale) med kommunikation om nedbrud via Incident Management-processen. Kategori C: Rapportering om nedbrud via Incident Management-processen. Kategori D: Rapportering om nedbrud via Incident Management-processen. Kategoriseringen af batchkørsler i et samt rapporternes specifikke indhold og layout aftales i forbindelse med udarbejdelse og godkendelse af Driftsaftalehåndbogen. YDL_052 Ophørsbistand Leverandøren skal levere ophørsbistand i overensstemmelse med kravene i bilag 20 (Ophørsbistand). YDL_053 Overordnede krav Leverandøren skal efter Overtagelsesdagen levere Ydelserne, herunder stille den tilstrækkelige kapacitet til rådighed, der er nødvendig for en sikker og stabil drift af det samlede Driftsmiljø i henhold til Servicemålene, jf. bilag 7 (Servicemål) og Kontraktens krav i øvrigt. YDL_054 Overordnede krav Der må ikke forekomme driftsforstyrrelser på grund af uvarslede overskridelser af kapaciteten. Leverandøren skal proaktivt gennem løbende kapacitetsplanlægning sikre, at miljøerne har tilstrækkelig lagerplads og øvrig kapacitet og yder en performance i henhold til de indgåede Servicemål. Kapacitetsplanlægningen skal ske gennem planlægning, overvågning af de samlede aktuelle leverancer, kvalitetsniveauer og forbrugsmængder samt gennem optimering og skalering af Driftsmiljøet. Resultatet af kapacitetsplanlægningen skal gennemgås med ATP i relevante samarbejdsfora jf. bilag 8 (Samarbejdsorganisation og Rapportering), med henblik på aftaler om skalering af kapacitet og vederlag. YDL_055 Overordnede krav K2 Leverandøren skal sikre et beredskab af kvalificerede ressourcer til varetagelse af timebaserede opgaver under Kontrakten. YDL_056 Overordnede krav K2 Leverandøren skal sikre opretholdelse af det niveau af kvalifikationer, der var gældende på tidspunktet for Overtagelsesdagen, med mindre andet eksplicit aftales med ATP. Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 58 / 66

59 Krav ID Kravgruppe Krav-type Kravtekst YDL_057 Overordnede krav MK Behandling af data må - af sikkerhedsmæssige årsager - alene finde sted inden for Danmarks grænser, jf. persondatalovens 41 og bogføringsloves 12, og det er derfor et krav, at Leverandøren ikke overfører data uden for landets grænser YDL_058 Overordnede krav K2 Leverandøren skal i forbindelse med fakturering af ATP levere behørig dokumentation for alle poster på den pågældende faktura, f.eks. ved hjælp af referencer til Change ID, projekt ID eller tilsvarende. Formkrav til dokumentationen aftales mellem ATP og Leverandøren i forbindelse med Leverandørens udarbejdelse af Driftsaftalehåndbogen. YDL_059 Overordnede krav K2 Leverandøren skal minimum en gang årligt gennemgå og fastlægge budget for det kommende år. Budgetlægningen skal ske i samarbejde med ATP og skal afspejle sæsonudsving, kendte fremtidige ændringer og lignende YDL_060 Overordnede krav K2 Leverandøren skal løbende følge op på budgetoverholdelse og rapportere til ATP i forbindelse med månedsrapporteringer, jf. bilag 8 (Samarbejdsorganisation og Rapportering). YDL_061 Overordnede krav K2 Eventuel bod skal opgøres på en særskilt specifikation med præcise angivelser af, hvilke forhold boden adresserer (bodsspecifikation). Boden opgøres jævnfør bodsmodellen, der beskrives i bilag 7 (Servicemål). Afregning af bod håndteres som udgangspunkt på særskilte kreditnotaer. YDL_062 Overordnede krav Leverandøren skal sikre personuafhængighed i opgaveløsningen. Denne personuafhængighed skal sikres gennem fyldestgørende dokumentation, intern videndeling og personaleoverlap under hensyntagen til behandlingen af fortrolig information YDL_063 Overordnede krav K2 Hvad angår Ydelserne skal Leverandøren én gang årligt fra Overtagelsesdagen udføre kundetilfredshedsundersøgelser for ATP s interne Brugere, som er direkte involveret i og gør brug af Ydelserne i ATP s organisation. Leverandøren skal sikre, at kundetilfredshedsundersøgelserne dækker et repræsentativt udvalg af interne Brugere, i hvert tilfælde omfattende de interne Brugere som rimeligt angivet af ATP. Tidspunkt, indhold, omfang og metode for kundetilfredshedsundersøgelserne aftales nærmere mellem Kunden og Leverandøren. Resultaterne af kundetilfredshedsundersøgelsen skal anvendes til diskussion mellem Parterne på det passende samarbejdsniveau i henhold til bilag 8 (Samarbejde og Rapportering). Hvis resultaterne af en kundetilfredshedsundersøgelse viser, at der har været en nedgang i kundetilfredsheden, skal Leverandøren, på ATP s anmodning, sende en passende og detaljeret plan for at forbedre kundetilfredsheden og opfylde alle de i nærværende bilag anførte krav. Planen skal fremsendes til ATP s godkendelse inden for 30 Dage efter Leverandørens modtagelse af ATP s anmodning om udarbejdelse af en sådan plan. Leverandøren skal sikre, at planen omfatter anvendelse af yderligere og andre ressourcer, såsom personale, ydelser og varer (om fornødent) og en plan for forbedring af overholdelsen af Servicemålene (hvis relevant). Efter ATP s godkendelse af planen, skal Leverandøren implementere planen og gennemføre en anden kundetilfredshedsundersøgelse inden for en periode, der ligger mellem tre (3) og seks (6) måneder efter ATP s godkendelse af planen. YDL_064 Overordnede krav For at sikre at Ydelserne leveres rettidigt, fejlfrit og i overensstemmelse med nærværende bilag, skal Leverandøren sikre, at alle Leverandørens Ændringer og/eller udvidelser af et er genstand for passende Afprøvning i overensstemmelse med Kontrakten og bilag 6 (Afprøvning), før de medtages i et og bruges som del af leveringen af Ydelser til ATP Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 59 / 66

60 Krav ID Kravgruppe Krav-type Kravtekst YDL_065 Overordnede krav K2 Leverandøren skal etablere, vedligeholde og gennemgå egne interne processer og procedurer i forhold til at afdække trusler eller risici i forbindelse med levering af Ydelserne, hvordan disse trusler og risici kan mindskes, og hvordan levering af Ydelserne kan opretholdes i tilfælde af, at en afdækket trussel eller risiko udmønter sig i faktiske leveranceproblemer. Disse interne processer og procedurer skal til enhver tid opfylde kravene i bilag 13 (Sikkerhed). YDL_066 Overordnede krav K2 Leverandøren skal i Løsningsbeskrivelsen udarbejde en backupstrategi for alle miljøer. Backupstrategien skal indeholde en retention plan og backup frekvens samt restoretid. YDL_067 Overordnede krav K2 Leverandøren er forpligtet til at levere de standardserviceydelser, som er defineret i bilag 5A (Standardserviceydelser). YDL_068 Overordnede krav Leverandøren er forpligtet til at etablere og deltage i samarbejdsorganisationen som beskrevet i bilag 8 (Samarbejdsorganisation og Rapportering). YDL_069 Problem management Leverandøren skal identificere og registrere Problems, hvor den bagvedliggende årsag til Incidents ikke er kendt eller ikke umiddelbart løses af incident Management. Registrering skal ske i samme ITSM system, som bruges til registrering af Incidents. Der skal kunne skelnes mellem Incidents og Problems ved angivelse af sagstype. YDL_070 Problem management K0 Leverandøren skal straks rapportere til ATP ved Problems, der påvirker vitale eller kritiske dele af det samlede miljø i henhold til Servicemålene i bilag 7 (Servicemål). YDL_071 Problem management Leverandøren skal foretage endelig afhjælpning for Problems, der falder inden for Leverandørens ansvarsområde og være ansvarlig for opfølgning på status, kommunikation, Servicemål og løsning indtil Incidentet er lukket. Viden oparbejdet i forbindelse med håndtering af Problems, herunder løsningsaktiviteter, skal yderligere dokumenteres i en løsningsdatabase. YDL_072 YDL_073 Problem management Problem management K2 K2 Leverandøren skal ved Problems, hvor der ikke kan findes fejl i Leverandørens ansvarsområde, registrere dette Problem i eget ITSM system og foretage en grundig vurdering af karakteren af det pågældende Problem, og hvis det vedrører en underleverandør (Leverandørens leverandør) eller ATP/ATP's Øvrige Leverandører, skal Leverandøren overlevere Problemet til underleverandøren eller ATP/ATP's Øvrige Leverandører og være ansvarlig for opfølgning på status, kommunikation, Servicemål og løsning indtil Incidentet er lukket jf. bilag 15 (L d k di i ) Leverandørens Problem Management skal løbende rapportere problem status til alle, der bidrager til løsning af problemet jf. Servicemålene i bilag 7 (Servicemål). YDL_074 Problem management K2 Leverandøren skal også initiere Problem sager på baggrund af følgende: Alle sager som ATP ønsker eskaleret overfor Leverandøren f.eks. pga. mange gentagne Incidents Alle major Incidents skal efter løsning/workaround initieres til root cause-analyse i en ny initieret Problem-sag. Trendanalyser foretaget i forbindelse med proaktiv Problem Management. YDL_075 Problem management K2 Leverandøren skal løbende, eventuelt i samarbejde med ATP s Øvrige Leverandører, foretage en opfølgning på Problem Management processen for at sikre erfaringsopsamling, der kan forbedre fremtidig fejlsøgning og løsning YDL_076 Problem management K2 ATP har til enhver tid mulighed for at anmode om, at der udarbejdes en Problem-sag på tilbagevendende Incidents, som opstår i Driftsmiljøet. YDL_077 Problem management K2 Leverandøren skal levere et overblik over åbne og lukkede Problems månedligt jf. bilag 8 (Samarbejdsorganisation og rapportering)]. Nærmere detaljer om behandling af rapporten aftales under udarbejdelse af Driftsaftalehåndbogen Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 60 / 66

61 Krav ID Kravgruppe Krav-type Kravtekst YDL_078 Problem management Leverandøren skal for hver prioritet 1 Incident udarbejde en redegørelse og sende til den ansvarlige Situation Manager i ATP. Redegørelsen skal som minimum indeholde følgende: Tidspunkt for fejlen (start slut) Kort beskrivelse af impact (berørte forretningsprocesser, antal brugere og perioden, hvor Incidenten var i gang). Løsningsbeskrivelse evt. work around for fejlhåndtering af Incidenten. Årsagsforklaring, hvis denne kendes på redegørelsestidspunktet. Hvis dette ikke er tilfældet, skal redegørelsen oplyse sagsnummer på den initierede problemsag, som efterfølgende undersøger root cause. Impact beskrivelse med angivelse af berørte og omfang. Forbedringsinitiativer for at undgå lignende fejl Navn på involverede medarbejdere til løsning inkl. navn på Leverandørens koordinerede ressource og tidspunkt for, hvornår denne ressource blev allokeret til løsning af Incidenten. YDL_079 Problem management K2 Root cause-analysen skal som minimum indeholde følgende: Kort beskrivelse af problem og berørte forretningsprocesser, brugere eller andet. Årsagsforklaring. Løsningsbeskrivelse. Iværksættelsesinitiativer for at undgå nye Incidents. Alle problemsager skal løbende opdateres med løsningsinitiativer YDL_080 Programmel K2 Alt Standardprogrammel skal, med mindre andet aftales med ATP, altid være opdateret i forhold til det af den relevante producent anbefalede patch-level og yderligere være i supporterede versioner. Der skal følges en fælles afstemt og godkendt patch procedure. Alle patches følger Change Management-processen. ATP skal altid godkende patches inden gennemførelse jf. bilag 7 (Servicemål). YDL_081 Release management K2 Leverandøren skal varsle nødvendige Release-skift herunder opgraderinger mindst 6 måneder forud. Release-skift skal begrundes og kan kun gennemføres, når ATP har godkendt. YDL_082 Release management K2 Leverandøren skal udføre og udarbejde Release-planer i forhold til Ydelserne, herunder ændringer, fejlrettelser, sikkerhedspatches mv., for godkendte ændringer/opgraderinger. YDL_083 Release management K2 Leverandøren skal sikre, at alle procedurer og checklister mv. i forbindelse med Releases er dokumenteret og gennemført i henhold til aftalte processer. Eksempelvis skal det i en checkliste markeres, at Changes er testet i de relevante testmiljøer og følger ATP testkrav jf. bilag 6 (Afprøvninger). YDL_084 Release management K2 Leverandøren er ansvarlig for selv at gennemføre Releases eller bistå ATP eller ATP s Øvrige Leverandører efter behov i henhold til Ydelserne. YDL_085 Release management K2 Leverandøren skal sikre den fornødne bemanding i forbindelse med servicevinduer til at foretage Changes, teknisk verifikation samt stå til rådighed under brugerverifikationen ved eventuelle fejlrettelser/fall back. YDL_086 Release management K2 Leverandøren skal følge ATP s retningslinjer for Release Management i bilag 2 (Situationsbeskrivelse) for at sikre, at relevante Changes inkluderes i pågældende Release. YDL_087 Release management K2 Leverandøren skal planlægge det fulde idriftsættelsesforløb fra en Change indmeldes i en Release over iværksættelse frem til fuld ibrugtagning. Af Leverandørens plan skal Leverandørens bemanding fremgå. Endvidere skal behov for koordinering med tredjeparter fremgå af planen. ATP skal godkende planen. Frist for ATP s modtagelse af planen forud for en Release aftales i forbindelse med udarbejdelse og godkendelse af Driftsaftalehåndbogen. YDL_088 Release management K2 ATP kan stille krav om, at Leverandøren befinder sig på ATP's lokationer eller en af ATP udpeget lokation i forbindelse med gennemførelsen af en Change. YDL_089 Release management Leverandøren skal efter implementeringen af en Change rapportere status til ATP. Ligeledes skal Leverandøren kontakte ATP uden unødigt ophold, hvis det konstateres, at der er risiko for, at en Change ikke kan implementeres succesfuldt Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 61 / 66

62 Krav ID Kravgruppe Krav-type Kravtekst YDL_090 Release management Såfremt det konstateres, at der er overhængende risiko for at en Change ikke kan implementeres succesfuldt, kan ATP til enhver tid kræve, at fall back-planen for den pågældende Change iværksættes. YDL_091 Service Operation K2 Leverandøren skal udstille en grænseflade mellem Leverandørens og ATP s IT service management-system (ITSM-system). Integrationen kan ske som WebService-kald, og skal fungere begge veje, så opdateringer i ATP's ITSM-system bliver replikeret til Leverandørens ITSM-system, og opdateringer i Leverandørens ITSM-system replikeres til ATP's ITSM-system. ATP vil selv foretage eventuelle tilpasninger i ATP s eget ITSM-system i et rimeligt omfang for at muliggøre integrationen med Leverandørens ITSMsystem. ATP s ITSM-system er beskrevet i bilag 2 (Situationsbeskrivelse), kapitel 9. YDL_092 Service Operation K2 Leverandørens skal senest syv dage efter verifikationen af idriftsættelse og endelige konvertering er godkendt, jf. bilag 6 (Afprøvninger), sikre, at alle udestående Fejl er oprettet i Leverandørens ITSM-system. YDL_093 Service Operation Leverandøren skal oprette en servicedesk som single point of contact for ATP's servicedesk. Kun autoriserede brugere fra ATP IT Service operation, som ATP har udpeget, kan rette henvendelse til Leverandørens Servicedesk. Leverandøren skal afvise at modtage henvendelse fra ikke-autoriserede personer. Leverandøren skal varetage 2. level fejlhåndteringssupport og dermed kunne sikre besvarelse og support af alle henvendelser fra ATP s servicedesk. ATP kan anvende Leverandørens servicedesk som én samlet servicedesk for hele Driftsmiljøet, også hvis fejlen skyldes forhold hos Øvrige YDL_094 Service Operation Selv om Leverandøren med rimelighed kan antage, at et rapporteret problem er relateret til programmel eller maskinel, der ikke er omfattet af Ydelserne, skal Leverandøren assistere med identifikation, diagnosticering og problemløsning. YDL_095 Service Operation K2 Leverandørens servicedesk skal desuden koordinere kommunikation mellem ATP, Øvrige Leverandører og Leverandøren i de tilfælde, hvor sagers løsning kræver dialog mellem disse parter, medmindre ATP k li i k å i d Leverandørens servicedesk skal være bemandet med dansktalende medarbejdere, der er uddannet til at varetage fejlhåndtering relateret til Ydelserne. Bemandingen bør som minimum have ITIL kompetencer på foundation-niveau eller tilsvarende. Leverandørens servicedesk skal i Arbejdstiden være bemandet i tilstrækkeligt omfang, således at unødig ventetid undgås, og skal kunne kontaktes via: , Telefon, Webinterface og ATP s eget ITSM-system Ved Incidents med prioritet 1, prioritet 2 og Problem Management skal ATP hurtigt og effektivt sættes i direkte dialog med/viderestilles til en af Leverandørens tekniske eksperter, hvis det er fordrende for en sags løsning. ATP skal ligeledes have mulighed for at tilgå relevante personer i forbindelse med normal afklaring og analyse i forhold til udarbejdelse af YDL_096 Service Operation K2 Inden en sag afsluttes kontaktes ATP for en bekræftelse af korrekt løsning af sagen, medmindre ATP eksplicit har frabedt sig dette. YDL_097 Service Operation Leverandøren skal understøtte brugen af ITIL version 3; det vil sige håndtere Incident, Change, Problem, Release og Configuration Management i henhold til ITIL version 3. Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 62 / 66

63 Krav ID Kravgruppe Krav-type Kravtekst YDL_098 Service Operation Ved Incidents der kategoriseres som prioritet 1, jævnfør bilag 7 (Servicemål), skal sagen eskaleres til situation Management og håndteres i overensstemmelse med beskrivelsen af situation Management i bilag 2 (Situationsbeskrivelse) YDL_099 Service Operation Leverandøren skal proaktivt konstatere og forebygge Problemer, fx ved at reducere eller helt forebygge Incidents, i forbindelse med løbende trendanalyser, som udføres i forbindelse med Ydelserne. Trendanalysen kan eksempelvis håndteres ved gennemgang af alle Incidents (både løste og uløste) for gentagne fejlmønstre og root causes. YDL_100 Service Operation Leverandøren skal til enhver tid kunne videregive samtlige oplysninger i en given supportsag, således at dokumentationen kan anvendes til drøftelse med ATP eller videregives til ATP s øvrige Leverandører. YDL_101 Service Operation K2 ATP har ret til at kræve alle sager (Incidents, Problems, Changes mv.) genåbnet, såfremt det konstateres, at den pågældende sag ikke er løst tilfredsstillende. Genåbnede sager skal håndteres af Leverandøren i henhold til den eller de relevante ITIL-processer. Leverandøren kan ikke lukke en genåbnet sag uden godkendelse fra ATP. YDL_102 YDL_103 Service Operation Sikkerhed og beredskab Leverandøren er forpligtet til at rette alle fejl og mangler i et, der betyder, at et ikke tilbyder den aftalte funktionalitet, jf. bilag 3 (Leverancebeskrivelse) eller ikke lever op til de aftalte servicemål, jf. bilag 7 (servicemål). Leverandøren er endvidere ansvarlig for at udbedre eventuelle fejl, der opstår som følge af idriftsættelsen af Releases. Fejlretningen skal ske i overensstemmelse med de opstillede servicemål i bil 7 (S i ål) ATP skal med én dags varsel have fysisk adgang til driftscentre op til fire gange årligt. Endvidere skal nøglepersoner fra ATP have fysisk adgang til backups uden unødig forsinkelse YDL_104 Sikkerhed og beredskab K0 Leverandøren skal udarbejde en detaljeret beredskabsplan, jf. bilag 4 (Dokumentation). Såfremt Leverandøren foretager ændringer i Ydelserne, som vedrører forhold der kan påvirke ATP, skal Leverandørens Beredskabsplan opdateres og ændringerne skal godkendes af ATP. Beredskabsplanen skal endvidere opdateres minimum én gang årligt. YDL_105 Sikkerhed og beredskab Leverandøren skal udpege en sikkerhedsansvarlig for hele kontraktperioden. Såfremt Leverandøren ønsker at udskifte den sikkerhedsansvarlige, skal dette meddeles ATP, som skal godkende valget af sikkerhedsansvarlig YDL_106 Sikkerhed og beredskab Leverandøren skal, i tillæg til Kontraktens pkt , dagligt varetage opdateringer af antivirussoftware (signaturfiler) og i øvrigt implementere automatisk virusscanning af alle filer, der tilgås on-demand på serverne. Identificeringen af virus skal medføre virusalarm til overvågningen. YDL_107 Sikkerhed og beredskab K2 Leverandøren er ansvarlig for at foretage årlig test af Leverandørens Disaster Recovery-plan i produktionsmiljøet i overensstemmelse med Servicemålene Bilag 7 (Servicemål). Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 63 / 66

64 Krav ID Kravgruppe Krav-type Kravtekst YDL_108 Sikkerhed og beredskab Leverandøren skal løbende foretage evaluering, opdatering og vedligeholdelse af egne procedurer i forhold til: Leverandørens fysiske og logiske adgang. Intern elektronisk kommunikation. Beskyttelse af personoplysninger. Tavshedspligt. Sletning af datamedier inkl. backup. Efterlevelse af ATP s it-sikkerhedspolitik og bestemmelser. Efterlevelse af Persondataloven, herunder Vejledning til bekendtgørelse nr. 528 af 15. juni Efterlevelse af Lov om finansiel virksomhed 71, herunder Vejledning 9074 af 23/01/2004. Efterlevelse af Lov 392 af 25. maj 2009, 11 & 12, herunder Økonomiog erhvervsministerens nærmere regler. Placering af ansvar, herunder ejerskab for it-processer og ressourcer. Overvågning af funktionsadskillelse. Kontrol med opretholdelse af det ønskede it-sikkerhedsniveau samt håndtering af eventuelle svagheder. Klassifikation og prioritering af systemer og data. Dokumentation af systemer (både basis- og brugersystemer) og ændringer. Sikkerhedskopiering af systemer og data, herunder opbevaring af sikkerhedskopierne. Anskaffelse af it-ressourcer. udvikling, konfigurering og vedligeholdelse, samt afprøvning af nye og ændrede systemer. Test og anden kvalitetssikring. Ændringshåndtering og Problemstyring. Adgangskontrol til systemer og data. YDL_109 Sikkerhed og beredskab Leverandøren skal foretage registrering af sikkerhedsmæssige hændelser i produktionsmiljøet. Hvad der nøjagtigt skal registreres aftales mellem ATP og Leverandøren i forbindelse med Leverandørens udarbejdelse af Driftsaftalehåndbogen. Leverandøren skal ligeledes foretage månedlig rapportering vedrørende de sikkerhedsmæssige forhold. Alle sikkerhedshændelser skal inddeles i kategorier efter alvorligheden af de enkelte hændelser. YDL_110 Sikkerhed og beredskab K2 Leverandøren skal have procedurer for adgangstildeling såvel fysisk som logisk. Der skal være en funktion, der sikrer og dokumenterer, at kun autoriseret personale kan få adgang til et. YDL_111 Sikkerhed og beredskab K0 Leverandøren må ikke uden ATP s forudgående godkendelse lagre ATP data på udstyr, der ikke er omfattet af Kontrakten hverken på lokale servere og/eller arbejdsstationer hos Leverandøren. YDL_112 Sikkerhed og beredskab Leverandøren skal uden unødigt ophold medvirke til at ATP kan leve op til sine lovmæssige forpligtelser for løsningen, herunder opfyldelsen af sikkerhedsmæssige krav, som påvirker ATP s mulighed for dette. YDL_113 Sikkerhed og beredskab Der skal etableres en informationssikkerhedspolitik, der som minimum lever op til ISO27001 og som skal kommunikere Leverandørens holdning til og engagement i informationssikkerhed, yde vejledning i forbindelse med sikkerhedsaktiviteter samt sætte forventningerne til medarbejdernes adfærd. YDL_114 Sikkerhed og beredskab et og netværk skal overvåges løbende. Dette for at opnå fokus på system- og netværksfejl, for at afsløre potentielle og faktiske angreb og for at understøtte undersøgelser. YDL_115 Sikkerhed og beredskab Både ATP's og Leverandørens Privilegerede brugere skal bruge stærke passwords og ændre deres passwords regelmæssigt. Endvidere skal Privilegerede brugeres aktiviteter logges, overvåges og gennemgås regelmæssigt YDL_116 Sikkerhed og beredskab Driftsmiljøet må alene deles med andre af Leverandørens kunder, såfremt det kan garanteres, at adskillelsen af miljøerne hos ATP og hos kunderne imellem er sikret, bl.a. ved at ATP s data alene kan ses af ATP, og at øvrige krav omfattet af Kontrakten kan overholdes. Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 64 / 66

65 Krav ID Kravgruppe Krav-type Kravtekst YDL_117 Sikkerhed og beredskab Der skal regelmæssigt og minimum 4 gange årligt udføres sårbarhedsskanninger på et ved anvendelse af alment anerkendte værktøjer til dette formål. ATP skal for hver skanning modtage en liste med fundne sårbarheder kategoriseret efter trusselsniveau samt en plan for udbedringer. Penetrationstest skal udføres minimum 1 gang årligt og ved større systemændringer. Penetrationstesten kan udføres af en selvstændig, uafhængig stabsafdeling hos Leverandøren. ATP forbeholder sig ret til at få penetrationstesten udført af en tredjepart, hvis Leverandørens egen test ikke lever op til markedsstandard. Ydelsen indeholdes i Driftsvederlaget. YDL_118 Sikkerhed og beredskab K2 Leverandøren skal vedligeholde relevante egne procedurer for sletning af datamedier. YDL_119 Sikkerhed og beredskab Seneste generation af fulde back-up og sikkerhedskopier skal opbevares forsvarligt på den primære lokation og på en anden geografisk lokation, end hvor et og data er lagret. YDL_120 Sikkerhed og beredskab Opdager Leverandøren en sikkerhedsbrist i sit eller ATP s miljø, som er relevant for Ydelserne, skal Leverandøren uden ugrundet ophold orientere ATP s sikkerhedsansvarlige om bristen og om hvem, der i perioden har haft adgang til ATP s miljøer. Derudover skal Leverandøren orientere ATP om, hvilke tiltag Leverandøren har gjort for at afbøde sikkerhedsbristen YDL_121 Sikkerhed og beredskab Leverandøren skal afprøve genetablering af databaser på udvalgte dele af Driftsmiljøet mindst én gang årligt og altid efter større Ændringer. Hvilke databaser afprøvning af genetablering skal foretages for, aftales med ATP under udarbejdelse af Driftsaftalehåndbogen, YDL_122 Sikkerhed og beredskab et skal fortsætte med at fungere i overensstemmelse med gældende Servicemål for et, hvis én eller flere integrationer er nede. et skal give ATP s kunderådgivere mulighed for at betjene borgere på de data, der er i et. YDL_123 Vedligeholdelse af et I Etape I, jf. bilag 1 (Tidsplan), skal Leverandøren sammen med ATP afklare, hvilke integrationer der nødvendige for ATP s brug af et, og hvordan et kan anvendes i de situationer, hvor én eller flere af d i i t ti d Leverandøren skal løbende vedligeholde et, herunder Programmel, og løbende idriftsætte opgraderinger for herigennem at sikre, at de fastsatte servicemål, jf. bilag 7 (Servicemål), overholdes. YDL_124 Vedligeholdelse af et Leverandøren skal ved vedligeholdelse af Programmel overholde kravene til Incident, Problem, Change og Release Management i nærværende bilag, og herigennem sikre, at de fastsatte servicemål overholdes, jf. bilag 7 (Servicemål) YDL_125 Vedligeholdelse af et Leverandøren skal løbende vedligeholde al intern og ekstern kommunikationsinfrastruktur i relation til Ydelserne, således at de fastsatte servicemål i bilag 7 (Servicemål) overholdes. YDL_126 Vedligeholdelse af et Leverandøren er forpligtet til at rette alle fejl og mangler i et, der betyder, at et ikke tilbyder den aftalte funktionalitet eller ikke lever op til de aftalte Servicemål, jf. bilag 7 (Servicemål). Fejlretningen skal ske i overensstemmelse med de opstillede Servicemål i bilag 7 (Servicemål). YDL_127 Vedligeholdelse af et K2 Leverandøren skal udarbejde og vedligeholde en plan for forebyggende vedligeholdelse på et. Planen skal løbende række 6 måneder frem og skal godkendes af ATP månedligt. YDL_128 Vedligeholdelse af et Leverandøren skal kontinuerligt monitorere, om der kommer nye relevante softwareopdateringer i form af patches, service packs og sikkerhedsopdateringer til Standardprogrammel, herunder værktøjer, og skal uden ugrundet ophold orientere ATP om nye releases (herunder hotfixes, sikkerhedspatches etc.) og versioner, når sådanne foreligger. YDL_129 Vedligeholdelse af et K2 Leverandøren skal monitorere, om der kommer opdateringer til eller nye versioner af fællesoffentlige komponenter med relevans for et. Ændringer til et som følge af opdateringer/nye versioner af fællesoffentlige komponenter skal ske i henhold til Change Managementprocessen mod særskilt betaling, medmindre det kan sandsynliggøres, at det falder inden for Leverandørens vedligeholdelsesforpligtelse. Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 65 / 66

66 Krav ID Kravgruppe Krav-type Kravtekst YDL_130 Vedligeholdelse af et Leverandøren skal implementere patches, service packs og sikkerhedsopdateringer eller nye releases/versioner af Standardprogrammel i overensstemmelse med Change Managementprocessen som en del af Driftsvederlaget, jf. bilag 5 (Priser og betalingsplan) YDL_131 Vedligeholdelse af et Leverandøren skal i overensstemmelse med den Change Management proces der endeligt aftales mellem Leverandøren og ATP i Driftsaftalehåndbogen foretage alle nødvendige tilretninger til et for at sikre overholdelsen af almen lovgivning, jf. lovgivningskravene i bilag 3A.1 (Kravliste), i hele kontraktperioden som en del af Driftsvederlaget jf bilag 5 (Priser og betalingsplan) YDL_132 Vedligeholdelse af et K2 Leverandøren skal i overensstemmelse med Change Managementprocessen foretage løbende vedligeholdelse og optimering af ets kildekode for: at minimere risiko for nedbrud (proaktive fejlrettelse), for at fremme ets performance, og for at sikre at et holdes teknisk ajour i kontraktperioden, som en del af Driftsvederlaget jf bilag 5 (Priser og betalingsplan) YDL_133 Videreudvikling af et K2 Projekter og større ændringer gennemføres i overensstemmelse med bilag 19 (Projektvilkår). YDL_134 Videreudvikling af et Leverandøren skal føre et nøjagtigt og detaljeret timeregnskab i forbindelse med levering af timebaserede ydelser. Timeregnskabet skal indeholde en opgørelse over forbrugt tid på den enkelte ydelse og den maksimale tidsenhed, der må anvendes i regnskabet, er én arbejdsdag. YDL_135 Videreudvikling af et K2 Timeregnskaberne skal føres således, at det specificerer hvilken medarbejder, hvilken dag, hvilken aktivitet og hvilken opgave Leverandøren f b skal d senest 6 måneder inden en opgradering oplyse, hvilke andre softwareprodukter og grænseflader i et, der er berørt af opgraderingen, og om disse kræver opgraderinger eller konfigurationsændringer. Formålet er at sikre, at ATP og Øvrige Leverandører kan tilpasse og matche deres applikationsportefølje til et ved opgraderinger. Leverandøren skal ved Overtagelsesdagen, som en del af Driftsaftalehåndbogen levere en plan for idriftsættelse af nye Versioner for de første 12 måneder. Det er herefter denne plan, der løbende d f d Krav til ydelser Bilag 03A.1 - Kravliste.xlsx Side 66 / 66