Nonfunktionelle krav by 7603kpW

VIEWS: 20 PAGES: 161

									        NAFS Krav
Samlet kravrapport
   Endelig version




               Udskrevet af TN
       Udskrevet den 15.12.2005
Forord
Vedlagte dokument indeholder forretningens krav til det fremtidige NAFS-system. Kravene skal ses
som et ligeværdigt supplement til de krav, der er udtrykt i procesdiagrammer og use cases.

Kravene er fremkommet med afsæt i RFI’en, NAFS-kontrakten med IBM (bilag 2 og 14b), samt krav
fremkommet under BPR-arbejdet i ATP-koncernen Q2 2005. Herefter er alle områder beriget med
yderligere krav med input fra domæneforretningsansvarlige, domænearkitekt/specialist og NAFS
kravspor i Q3 2005.

Efter kravenes tilblivelse er der defineret en NAFS systemløsning, der i første omgang ikke
implementerer alle krav. Til- og fravalg er foretaget af NAFS Change Control Board i samarbejde med
NAFS-programledelse i Q4 2005. Krav, der er ikke implementeres fuldt ud i NAFS version 1, er i
denne rapport markeret med X forrest i kravnavnet. Til nærværende dokument hører en log over de
ændringer – incl. X-markeringer – der er foretaget i denne udgave af kravrapporten i forhold til 15.10-
udgaven. Loggen beskriver i detaljer kravopfyldelsesgraden for de X-markerede krav.

At et krav er fravalgt i første omgang, betyder ikke at leverandørerne kan se bort fra disse
krav. Kravene skal på lige fod med alle øvrige krav tænkes ind i designet af den samlede løsning,
således at det sikres, at systemet bliver rummeligt nok til at kunne opfylde samtlige krav.

De fravalgte krav er defineret ude af NAFS-programmets scope, men forventes implementeret på et
givent tidspunkt senere.



Tina Nielsen/Morten Nilsson
December 2005




                                                                            Side I
Indhold
1    A TVÆRGÅENDE ........................................................................................................................................................................... 12
    1.1    Visionskrav(TV)...................................................................................................................................................................... 12
        1.1.1    Standardsystem til flere juridiske enheder(TV) ............................................................................................................. 12
        1.1.2    Koncernkunde arbejder via portal(TV) .......................................................................................................................... 13
        1.1.3    Time to market(TV) ...................................................................................................................................................... 13
        1.1.4    Ændring af parametre uden programændring(TV) ....................................................................................................... 13
    1.2    Klagehåndtering(TV) .............................................................................................................................................................. 13
        1.2.1    Håndtering af mundtlige klager(TV) .............................................................................................................................. 13
        1.2.2    Håndtering af skriftlige klager og ankesager(TV) ......................................................................................................... 14
    1.3    Generel funktionalitet(TV) ...................................................................................................................................................... 14
        1.3.1    Datatilgængelighed på laveste niveau(TV) ................................................................................................................... 15
        1.3.2    Brugeroplevet svartid(TV)............................................................................................................................................. 15
        1.3.3    Valutaneutralitet(TV) .................................................................................................................................................... 16
        1.3.4    Kustodefunktioner (TV)................................................................................................................................................. 16
        1.3.5    Genbrug af funktioner på tværs af målgrupper(TV) ...................................................................................................... 16
        1.3.6    Kunderådgiver agerer som slutkunde(TV) .................................................................................................................... 17
        1.3.7    Håndtering af fejl og afvigelser(TV) .............................................................................................................................. 17
        1.3.8    Genbrug af slutkundeinformationer(TV) ....................................................................................................................... 17
        1.3.9    Samtykke på tværs af ordninger(TV) ............................................................................................................................ 18
        1.3.10 Noter(TV)...................................................................................................................................................................... 19
        1.3.11 Totalintegration(TV) ...................................................................................................................................................... 19
        1.3.12 Validering af data(TV) .................................................................................................................................................. 19
        1.3.13 Udenlandske slutkunder(TV) ........................................................................................................................................ 20
        1.3.14 Udenlandske virksomheder(TV) ................................................................................................................................... 20
        1.3.15 Tilbagerulning(TV) ........................................................................................................................................................ 20
        1.3.16 Iværksættelser(TV) ....................................................................................................................................................... 20
        1.3.17 Anmeldelse til Datatilsynet(TV) .................................................................................................................................... 21
    1.4    Koncernkunder og Ydelseskatalog (TV) ................................................................................................................................ 21
        1.4.1    X - Ydelseskatalog(TV)................................................................................................................................................. 21
        1.4.2    X - Oprettelse af koncernkundeaftaler(TV) ................................................................................................................... 21
        1.4.3    X - Kontrakt/drifts periode(TV) ...................................................................................................................................... 22
        1.4.4    X - Afvikling af koncernkundeaftale(TV) ....................................................................................................................... 22
        1.4.5    X - Koncernkundernes adgang til data(TV) .................................................................................................................. 22
        1.4.6    X - Klikke tillægsfunktionalitet fra/til (TV) ...................................................................................................................... 23
        1.4.7    X - Print af kundespecifik forretningsgang(TV) ............................................................................................................. 23
    1.5    Tekniske og arkitektur krav(TV) ............................................................................................................................................. 23
        1.5.1    Grænseflader(TV) ........................................................................................................................................................ 23
        1.5.2    Skalerbarhed(TV) ......................................................................................................................................................... 23
        1.5.3    Sanering af data/registreringer(TV) .............................................................................................................................. 24
        1.5.4    Single sign on(TV) ........................................................................................................................................................ 24
        1.5.5    Rollemodellen(TV) ........................................................................................................................................................ 24
2       B PORTALER ............................................................................................................................................................................. 25
    2.1    Selvbetjeningsfunktionalitet ................................................................................................................................................... 26
        2.1.1    Mulighed for at beregne diverse prognoser(Portal) ...................................................................................................... 26
        2.1.2    Prognoseberegninger gemmes automatisk(Portal) ...................................................................................................... 26
        2.1.3    Datafangst ved selvbetjeningsfunktionalitet(Portal) ...................................................................................................... 26
    2.2    Generel funktionalitet ............................................................................................................................................................. 27
        2.2.1    Visionskrav (Portal) ...................................................................................................................................................... 27
        2.2.2    Fejltolerant brugerdialog(Portal) ................................................................................................................................... 27
        2.2.3    Navigation mellem skærm og data(Portal) ................................................................................................................... 27
        2.2.4    Effektiv brugerdialog(Portal) ......................................................................................................................................... 28
        2.2.5    Flere åbne applikationer samtidig(Portal) ..................................................................................................................... 28
        2.2.6    Online-hjælp(Portal) ..................................................................................................................................................... 29
        2.2.7    Menuer/funktioner og fejlbeskeder på dansk(Portal) .................................................................................................... 29
        2.2.8    Webstatistikker(Portal) ................................................................................................................................................. 29
        2.2.9    Portaltyper og portalfunktionalitet(Portal) ..................................................................................................................... 30
        2.2.10 Andre kommunikationsmedier(Portal) .......................................................................................................................... 31
        2.2.11 Dybe links(Portal) ......................................................................................................................................................... 31



                                                                                                                                                Side I
          2.2.12 Søgning(Portal) ............................................................................................................................................................ 31
          2.2.13 Sammenhængende brugergrænseflade(Portal) ........................................................................................................... 32
          2.2.14 Opkobling af selvbetjeningsapplikationer til eksterne portaler(Portal) .......................................................................... 32
          2.2.15 Genbrug af portlets(Portal) ........................................................................................................................................... 32
          2.2.16 Browser/styresystemer(Portal) ..................................................................................................................................... 32
          2.2.17 Print(Portal) .................................................................................................................................................................. 33
          2.2.18 Overholdelse af design- og strukturmanual(Portal) ...................................................................................................... 33
          2.2.19 Visuel kvittering(Portal)................................................................................................................................................. 34
          2.2.20 Fælles portal med fælles struktur m.v(Portal) ............................................................................................................... 34
          2.2.21 Automatisk visning af dokumenter mv.(Portal) ............................................................................................................. 34
3         C WORKFLOW........................................................................................................................................................................... 36
    3.1      Generelt(WF) ......................................................................................................................................................................... 37
          3.1.1    Overordnede visioner/krav(WF) ................................................................................................................................... 37
          3.1.2    Sager/Processer relateres til flere juridiske enheder(WF) ............................................................................................ 37
          3.1.3    Processer skal have et variable antal aktiviteter(WF) ................................................................................................... 38
          3.1.4    Alle data relateret til en sag fremstå i seneste version(WF) ......................................................................................... 38
          3.1.5    Tidsfrist og alarmer(WF) ............................................................................................................................................... 38
          3.1.6    Udføre parallel aktiviteter(WF)...................................................................................................................................... 38
          3.1.7    Push/pull(WF)............................................................................................................................................................... 39
          3.1.8    Migrere sager til andre medier(WF) .............................................................................................................................. 39
          3.1.9    Parameterstyrede forretningregler(WF) ........................................................................................................................ 39
          3.1.10 Håndtere både strukturerede og ustrukturerede flows(WF).......................................................................................... 39
          3.1.11 Tilgængelig information for aktiviteter(WF) ................................................................................................................... 40
          3.1.12 Tilgængelig information ved hver afsluttet proces(WF) ................................................................................................ 40
          3.1.13 Aktiviteter kan sorteres(WF) ......................................................................................................................................... 41
          3.1.14 Søgning på aktiviteter(WF) ........................................................................................................................................... 41
          3.1.15 Aktivitet ikke automatisk gennemføres afsluttes(WF) ................................................................................................... 41
          3.1.16 Flytning af aktivitet uden om regler(WF) ....................................................................................................................... 41
          3.1.17 Aktiviteter kan tvinges til afslutning(WF) ....................................................................................................................... 41
          3.1.18 Processer kan tvinges til afslutning(WF) ...................................................................................................................... 42
    3.2      Udvikling og vedligehold af forretningsgange(WF)................................................................................................................. 42
          3.2.1    Intuitiv grafisk interface for designeren(WF) ................................................................................................................. 42
          3.2.2    Allokerings Logik - Parameter(WF) .............................................................................................................................. 42
          3.2.3    X - Rettelser i flow- og allokeringslogik (WF) ................................................................................................................ 43
          3.2.4    Aktivitets Definition understøtter forskellige status(WF) ............................................................................................... 43
          3.2.5    Aktivitets Instans understøtter forskellige status(WF) ................................................................................................... 43
          3.2.6    Allokerings regler tilrettes af teamleder(WF) ................................................................................................................ 43
          3.2.7    Genbrug af processer på tværs(WF) ............................................................................................................................ 44
          3.2.8    Identifikation af processer(WF)..................................................................................................................................... 44
          3.2.9    Identifikation af aktiviteter(WF) ..................................................................................................................................... 44
          3.2.10 Design af processer som superbruger(WF).................................................................................................................. 45
          3.2.11 Simulering og løbende ændringer(WF) ........................................................................................................................ 45
          3.2.12 Ændring af parameter on the fly(WF) ........................................................................................................................... 45
          3.2.13 Proces Definition understøtte forskellige status(WF) .................................................................................................... 46
          3.2.14 Proces Instans understøtter forskellige status(WF) ...................................................................................................... 46
          3.2.15 Indsætte målepunkter(WF) ........................................................................................................................................... 46
    3.3      Brugergrænseflade/interface (WF)......................................................................................................................................... 46
          3.3.1    Grafisk illustration af processer med behandlingstider(WF) ......................................................................................... 46
          3.3.2    Browser baseret console(WF) ...................................................................................................................................... 47
          3.3.3    X - Workflow styring -ledelse- skal indgå som portlet(WF) ........................................................................................... 47
          3.3.4    Indbakke skal indgå i portalen som portlet(WF) ........................................................................................................... 47
    3.4      Workflows interaktion med andre systemer(WF) ................................................................................................................... 47
          3.4.1    Processer startes fra notifikationer (WF) ...................................................................................................................... 48
          3.4.2    Hent data fra WF og lagres i journalsystemet(WF)....................................................................................................... 48
          3.4.3    Registrering i journalsystemet skal trigge et WF(WF) .................................................................................................. 48
          3.4.4    Understøtte både synkrone og asynkrone interaktioner(WF) ....................................................................................... 48
    3.5      Rapportering(WF) .................................................................................................................................................................. 48
          3.5.1    Online rapportering(WF) ............................................................................................................................................... 49
          3.5.2    X - Retrospektivt/tilbageskuende billede(WF)............................................................................................................... 49
          3.5.3    Rapportering for returneret aktivitet(WF) ...................................................................................................................... 49


                                                                                                                                                  Side I
          3.5.4    Rapportering for aktiviteternes rækkefølge(WF)........................................................................................................... 49
          3.5.5    Operationel rapportering(WF)....................................................................................................................................... 50
          3.5.6    X - Operationel rapportering- forventet ressourceforbrug(WF) ..................................................................................... 50
    3.6      Opgavestyring/opfølgning(WF) .............................................................................................................................................. 50
          3.6.1    X - Se belastningen på processer(WF) ........................................................................................................................ 50
          3.6.2    Monitorering og flaskehalse(WF) .................................................................................................................................. 50
          3.6.3    Monitorering foretages efter forskellige kriterier(WF) ................................................................................................... 51
          3.6.4    Effektivitets måling(WF)................................................................................................................................................ 51
          3.6.5    Opsætte alarmering på servicemål(WF) ....................................................................................................................... 51
          3.6.6    Prioritering af aktiviteter(WF) ........................................................................................................................................ 51
          3.6.7    X - Forventede ressourcetræk skal kunne beregnes(WF) ............................................................................................ 52
          3.6.8    Opgave/taskliste og portlets(WF) ................................................................................................................................. 52
          3.6.9    Tydeliggørelse at en alarm er overskrevet(WF) ........................................................................................................... 52
          3.6.10 Administration/styring(WF) ........................................................................................................................................... 52
          3.6.11 Forretningsmæssig prioritering(WF) ............................................................................................................................. 53
          3.6.12 Simulering(WF) ............................................................................................................................................................ 53
          3.6.13 Operationelle ledelse(WF) ............................................................................................................................................ 53
          3.6.14 Arbejdsredskab til opgavestyring(WF) .......................................................................................................................... 53
          3.6.15 Levere gennemsnit for opfølgning på SLA(WF) ........................................................................................................... 54
    3.7      Roller(WF).............................................................................................................................................................................. 54
          3.7.1    Håndtere forskellige rolle begreber(WF) ...................................................................................................................... 54
          3.7.2    Roller skal kunne defineres i TIM og anvendes i WF(WF)............................................................................................ 54
          3.7.3    Skal kunne melde personer ind/ud af en rolleliste(WF) ................................................................................................ 54
          3.7.4    Medarbejder kan have flere roller(WF) ......................................................................................................................... 55
4         D INTERESSENT ....................................................................................................................................................................... 56
    4.1      Interessent ............................................................................................................................................................................. 56
          4.1.1    Automatisk sagsbehandlingsforløb(INT)....................................................................................................................... 56
          4.1.2    Adskillelse af data fra offentlige registre og atps egne data(INT) ................................................................................. 58
          4.1.3    Modtagelse af data fra ASK(INT) ................................................................................................................................. 59
          4.1.4    Administration af elektroniske postadresser(INT) ......................................................................................................... 59
          4.1.5    Kontakttyper/hierarki på virksomhedsniveau(INT) ........................................................................................................ 60
          4.1.6    Håndtering af forældre/barn relationer(INT) ................................................................................................................. 60
          4.1.7    Oversigt over ordningernes adgang til interessentdata(CRM) ...................................................................................... 61
          4.1.8    Interessenter som objekter(INT) ................................................................................................................................... 61
          4.1.9    Mulighed for outsourcing(INT) ...................................................................................................................................... 61
          4.1.10 Flere SE-nr. knyttet til en virksomhed(INT) ................................................................................................................... 62
          4.1.11 Søgning på interessent(INT) ........................................................................................................................................ 62
5         F CRM ........................................................................................................................................................................................ 63
    5.1      Forretning(CRM) .................................................................................................................................................................... 63
          5.1.1    Adgang til alle relevante oplysninger(CRM) ................................................................................................................. 63
          5.1.2    Så få niveauer i systemet som muligt(CRM) ................................................................................................................ 63
          5.1.3    Opdatering i 360-graders-billedet. (CRM)..................................................................................................................... 64
          5.1.4    Alle ordninger i 360-graders billedet(CRM) .................................................................................................................. 64
          5.1.5    Ordningsspecifikke info fremgå af 360-grader (CRM) .................................................................................................. 64
          5.1.6    Mulighed for at skifte mellem ordninger(CRM) ............................................................................................................. 65
          5.1.7    Vis info på tværs af kundegrupper(CRM) ..................................................................................................................... 65
          5.1.8    360-graders billedet viser relevant info(CRM) .............................................................................................................. 65
          5.1.9    Nyt CPR/SE-nummer skal kunne indtastes direkte(CRM) ............................................................................................ 65
          5.1.10 Identifikation af relevante informationer(CRM) ............................................................................................................. 66
          5.1.11 X - Identifikation af kunde(CRM) .................................................................................................................................. 66
          5.1.12 Info om hvor i en proces bruger befinder sig(CRM) ...................................................................................................... 66
          5.1.13 Log over ind- og udgående kundetransaktioner(CRM) ................................................................................................. 66
          5.1.14 Lister over transakt. indeholder relevant info(CRM) ..................................................................................................... 67
          5.1.15 Lister over transakt. med links til relevant info(CRM) ................................................................................................... 67
          5.1.16 Mulighed for let at sortere og filtrere listen(CRM) ......................................................................................................... 67
          5.1.17 Bruger og registrering af kundekorrespond.(CRM) ....................................................................................................... 67
          5.1.18 Seneste 3 transaktioner på 360 graders billedet(CRM) ................................................................................................ 68
          5.1.19 X - Registrering af kundens ønsker(CRM).................................................................................................................... 68
          5.1.20 Samtaletid for aktive kundesamtaler(CRM) .................................................................................................................. 68
          5.1.21 Se overenskomst- oplysninger(CRM) ........................................................................................................................... 68


                                                                                                                                                     Side I
        5.1.22 Se renteoplysninger på 360 grader(CRM) .................................................................................................................... 69
        5.1.23 X - Automatisk information til kunderådgiver/slutkunde(CRM) ..................................................................................... 69
        5.1.24 Ændring af info på 360 grader billede(CRM) ................................................................................................................ 69
    5.2    Marketing(CRM) ..................................................................................................................................................................... 70
        5.2.1    X - Analyse af persondata(CRM) .................................................................................................................................. 70
        5.2.2    Analyse af stamdata(CRM) .......................................................................................................................................... 70
        5.2.3    X - Analyse af holdningsdata(CRM) ............................................................................................................................. 70
        5.2.4    X - Analyse af kontaktdata(CRM) ................................................................................................................................. 71
        5.2.5    X - Analyse af IT-understøttelse(CRM)......................................................................................................................... 71
        5.2.6    Visning af samtykke i 360-graders billede(CRM) .......................................................................................................... 71
        5.2.7    Udtræk ordningsspecifikkke data(CRM) ....................................................................................................................... 72
        5.2.8    X - Segmentering på relevante data(CRM) .................................................................................................................. 72
        5.2.9    X - Segmentering på kampagnedata(CRM) ................................................................................................................. 72
        5.2.10 X - Integration af kampagnemodul(CRM) ..................................................................................................................... 72
        5.2.11 FAQ-lister(CRM) ........................................................................................................................................................... 73
        5.2.12 X - Effektmåling(CRM).................................................................................................................................................. 73
        5.2.13 X - Registrering af kampagnerespons(CRM)................................................................................................................ 73
        5.2.14 X - Registrering af kunderettede aktviteter mv.(CRM) .................................................................................................. 74
        5.2.15 X - Rapportering af kampagnerespons(CRM) .............................................................................................................. 74
        5.2.16 X - Identifikation af målgrupper(CRM) .......................................................................................................................... 74
        5.2.17 X - Udvælgelse af målgrupper(CRM) ........................................................................................................................... 74
        5.2.18 X - Kampagneregistrering for målgruppe(CRM) ........................................................................................................... 75
        5.2.19 X - Regelstyring for kunderettet kommunikation(CRM) ................................................................................................ 75
        5.2.20 X - CRM på webben(CRM) ........................................................................................................................................... 75
    5.3    Analytisk CRM ....................................................................................................................................................................... 76
        5.3.1    Informartionsbærende data i analysemart(CRM) ......................................................................................................... 76
        5.3.2    Opsamling af kundens kanalvalg(CRM ........................................................................................................................ 76
        5.3.3    Kategorisere kundehenvendelser(CRM) ...................................................................................................................... 76
        5.3.4    X - Resultater fra spørgeskemaerne ind i en analysemart(CRM) ................................................................................. 77
        5.3.5    X - Resultat fra analytisk CRM ind i 360 graders billede(CRM) .................................................................................... 77
        5.3.6    X - Håndtering af spørgeskemaer(CRM) ...................................................................................................................... 77
        5.3.7    X - Vedligeholdelse af spørgeskemaer(CRM) .............................................................................................................. 77
        5.3.8    X - Driften af spørgeskemaer(CRM) ............................................................................................................................. 78
        5.3.9    Datafangst ved selvbetjeningsfunktionalitet(Portal) ...................................................................................................... 78
6       G CALL CENTER ....................................................................................................................................................................... 79
    6.1    Call Center ............................................................................................................................................................................. 80
        6.1.1    Fuldt programmerbart(CC) ........................................................................................................................................... 80
        6.1.2    X - Tidstro ændring(CC) ............................................................................................................................................... 80
        6.1.3    Intelligent routning af opkald(CC) ................................................................................................................................. 80
        6.1.4    X - Mulighed for ændring i opsætning(CC) ................................................................................................................... 81
        6.1.5    360 graders billede(CC) ............................................................................................................................................... 81
        6.1.6    Kundeselvbetjening(CC)............................................................................................................................................... 81
        6.1.7    X - Outbound aktiviteter(CC) ........................................................................................................................................ 82
        6.1.8    70èr numre(CC) ........................................................................................................................................................... 82
        6.1.9    Ad hoc meddelelser(CC) .............................................................................................................................................. 83
        6.1.10 X - Co-browsing(CC) .................................................................................................................................................... 83
        6.1.11 Warning ved overskridelse af servicemål(CC) .............................................................................................................. 83
        6.1.12 Kampagne-telefonnumre(CC) ...................................................................................................................................... 84
        6.1.13 Beredskab af voices(CC).............................................................................................................................................. 84
        6.1.14 Call back og SMS(CC) ................................................................................................................................................. 84
        6.1.15 Hændelsestyret organisering(CC) ................................................................................................................................ 84
        6.1.16 Betjening via flere filtre(CC).......................................................................................................................................... 85
        6.1.17 Direkte afsendelse af bekræftelse(CC)......................................................................................................................... 85
        6.1.18 Servicetelefon med talegenkendelse(CC) .................................................................................................................... 85
        6.1.19 Alarm funktion for call back(CC) ................................................................................................................................... 85
        6.1.20 Statistikker(CC) ............................................................................................................................................................ 86
        6.1.21 Planlægning af produktion(CC) .................................................................................................................................... 86
        6.1.22 X - Lyt med agent(CC).................................................................................................................................................. 86
        6.1.23 X - Optagelse af tlf.samtaler(CC) ................................................................................................................................. 87
7       H DOKUMENTHÅNDTERING .................................................................................................................................................... 88


                                                                                                                                                  Side I
      7.1 Journalisering (DH) ................................................................................................................................................................ 89
       7.1.1    Journalisering af dokumenter (DH) ............................................................................................................................... 89
       7.1.2    Metadata (DH) .............................................................................................................................................................. 89
   7.2    Visning (DH)........................................................................................................................................................................... 89
       7.2.1    Preprint visning (DH) .................................................................................................................................................... 89
       7.2.2    Visning af dokument (DH) ............................................................................................................................................ 90
   7.3    Lagring (DH) .......................................................................................................................................................................... 90
       7.3.1    Søgning (DH) ............................................................................................................................................................... 90
       7.3.2    Arkivoverblik (DH) ........................................................................................................................................................ 90
   7.4    Capture (datamodtagelse) (DH) ............................................................................................................................................. 90
       7.4.1    X - Scanning (DH) ........................................................................................................................................................ 91
       7.4.2    Icr-fortolkning (DH) ....................................................................................................................................................... 91
       7.4.3    Fuldtekst genkendelse (DH) ......................................................................................................................................... 91
       7.4.4    Kanaler, medier og formater (DH) ................................................................................................................................ 91
       7.4.5    Returpost (DH) ............................................................................................................................................................. 92
   7.5    Dokumentudvikling (DH) ........................................................................................................................................................ 93
       7.5.1    Print af dokumenter (DH).............................................................................................................................................. 93
       7.5.2    X - Udsendelsesperformance (DH) .............................................................................................................................. 93
       7.5.3    Genudskrive breve (DH) ............................................................................................................................................... 94
       7.5.4    Samkuvertering (DH) .................................................................................................................................................... 94
       7.5.5    Kanalvalg (DH) ............................................................................................................................................................. 94
       7.5.6    Bundtning ifm masseudsendelser(DH) ......................................................................................................................... 95
       7.5.7    Individualiserede breve (DH) ........................................................................................................................................ 95
       7.5.8    Branding (DH) .............................................................................................................................................................. 95
       7.5.9    Underskriftsfil (DH) ....................................................................................................................................................... 96
       7.5.10 Sprog (DH) ................................................................................................................................................................... 96
       7.5.11 Datering af breve (DH) ................................................................................................................................................. 96
       7.5.12 Anvendelse af tekstelementer på tværs (DH) ............................................................................................................... 96
       7.5.13 Ændringer i breve (DH) ................................................................................................................................................ 97
       7.5.14 Understøttet brevindhold (DH)...................................................................................................................................... 97
       7.5.15 Fritekst (DH) ................................................................................................................................................................. 98
       7.5.16 Hentning af fritekster (DH) ............................................................................................................................................ 98
8      I EKSTERN KOMMUNIKATION ................................................................................................................................................. 99
   8.1    Ekstern Kommunikation ......................................................................................................................................................... 99
       8.1.1    Standardformat for dataudveksling(EK)........................................................................................................................ 99
       8.1.2    Dataudveksling batch(EK) .......................................................................................................................................... 100
       8.1.3    Dataudveksling online (EK) ........................................................................................................................................ 100
       8.1.4    Leverancestyring (EK) ................................................................................................................................................ 100
       8.1.5    Kustodefunktioner(EK) ............................................................................................................................................... 101
       8.1.6    Logning (EK) .............................................................................................................................................................. 101
9      J JURIDISK AFDELING(JURS) ................................................................................................................................................ 102
   9.1    Lovmæssige krav ................................................................................................................................................................. 104
       9.1.1    Dataopbevaringstid(JURS) ......................................................................................................................................... 104
       9.1.2    Fortrolighed(JURS) .................................................................................................................................................... 104
       9.1.3    Overholdelse af lovgivning -generelt(JURS)............................................................................................................... 105
       9.1.4    Autencitet-Integritet-Uafviselighed(JURS) .................................................................................................................. 105
       9.1.5    Arbejdsmiljøkrav(JURS) ............................................................................................................................................. 105
       9.1.6    Elektronisk kommunikation(JURS) ............................................................................................................................. 106
       9.1.7    Sporbarhed(JURS) ..................................................................................................................................................... 106
       9.1.8    Egenacces(JURS) ...................................................................................................................................................... 106
       9.1.9    Aktindsigt(JURS) ........................................................................................................................................................ 107
       9.1.10 Effektive journalsystemer(JURS) ................................................................................................................................ 107
       9.1.11 Fristregler(JURS) ....................................................................................................................................................... 107
       9.1.12 Arkivering(JURS) ........................................................................................................................................................ 107
       9.1.13 Partshøring(JURS) ..................................................................................................................................................... 108
       9.1.14 Opbevaringspligt/sagsdokumentation(JURS) ............................................................................................................. 108
       9.1.15 Skriftlighed(JURS) ...................................................................................................................................................... 108
       9.1.16 Behandlingssikkerhed(JURS)..................................................................................................................................... 108
10     K INTERN REVISION(IREV) .................................................................................................................................................... 110
   10.1 Revisionsmæssige krav ....................................................................................................................................................... 112


                                                                                                                                                 Side I
       10.1.1 Overordnede krav(IREV) ............................................................................................................................................ 112
       10.1.2 Fortrolighed(IREV) ..................................................................................................................................................... 112
       10.1.3 Tilgængelighed(IREV) ................................................................................................................................................ 113
       10.1.4 Kontrol- og transaktionsspor(IREV) ............................................................................................................................ 113
       10.1.5 Integritet(IREV)........................................................................................................................................................... 113
       10.1.6 Uafviselighed(IREV) ................................................................................................................................................... 113
       10.1.7 Fuldstændighed generelt(IREV) ................................................................................................................................. 115
       10.1.8 Fuldstændighed ved inddata(IREV) ........................................................................................................................... 115
       10.1.9 Fuldstændighed ved funktionter og registre(IREV) ..................................................................................................... 115
       10.1.10    Fuldstændighed ved uddata(IREV) ....................................................................................................................... 115
       10.1.11 Nøjagtighed vedr. inddata(IREV) ................................................................................................................................ 116
       10.1.12    Nøjagtighed vedr. funktioner og registre(IREV) ..................................................................................................... 116
       10.1.13    Nøjagtighed vedr. uddata(IREV) ............................................................................................................................ 116
       10.1.14    Rettidigheden vedr. inddata(IREV) ........................................................................................................................ 117
       10.1.15    Rettidigheden vedr. funktioner og registre(IREV) .................................................................................................. 117
       10.1.16    Rettidigheden vedr. uddata(IREV) ......................................................................................................................... 117
       10.1.17    Godkendte transaktioner-Generelt(IREV) .............................................................................................................. 117
       10.1.18    Godkendte transaktioner vedr. inddata(IREV) ....................................................................................................... 118
       10.1.19    Godkendte transaktioner vedr. funktioner og registre(IREV) ................................................................................. 118
       10.1.20    Godkendte transaktioner vedr. uddata(IREV) ........................................................................................................ 118
11     L IT-ARKITEKTUR(ITAR) ......................................................................................................................................................... 120
   11.1 Applikationsdesign(ITAR) .................................................................................................................................................... 120
       11.1.1 Komponentbaseret og serviceorienteret(ITAR) .......................................................................................................... 120
       11.1.2 System opdelt i komponenter(ITAR) .......................................................................................................................... 121
       11.1.3 Samme begreber overalt(ITAR) ................................................................................................................................. 121
       11.1.4 Tilgængelighed - findes også som Driftskrav (ITAR) .................................................................................................. 121
       11.1.5 Løs kobling mellem domæner og eksterne samarbejdspartnere(ITAR) ..................................................................... 122
       11.1.6 Effektiv håndtering, fremsøgning og lagring af information og data på tværs af ATP(ITAR) ...................................... 122
       11.1.7 Ingen forretningsregler i brugergrænseflade(ITAR) .................................................................................................... 122
       11.1.8 X - Løsning skal passe ind i ATP_s Teknologi model og Teknisk infrastrukturmodel(ITAR) ...................................... 122
       11.1.9 Løsnings dokumentation(ITAR) .................................................................................................................................. 123
       11.1.10 X - Historik(ITAR) ....................................................................................................................................................... 123
   11.2 Integration(ITAR) ................................................................................................................................................................. 123
       11.2.1 Integration mellem købe-systemer og egenudviklede komponenter (ITAR) ............................................................... 123
       11.2.2 Sporbarhed på tværs af systemer(ITAR) .................................................................................................................... 123
   11.3 Sikkerhed(ITAR) .................................................................................................................................................................. 124
       11.3.1 X - Sikkerhedsprincipper(ITAR) .................................................................................................................................. 124
       11.3.2 X - Sikkerhedsarkitekturen baseret på RBAC(ITAR) .................................................................................................. 124
       11.3.3 Autenticitet(ITAR) ....................................................................................................................................................... 125
       11.3.4 Konfidentialitet(ITAR) ................................................................................................................................................. 125
       11.3.5 Uafviselighed(ITAR) ................................................................................................................................................... 125
       11.3.6 Autorisation(ITAR) ...................................................................................................................................................... 126
       11.3.7 Formel autorisationsprocedure- og arbejdsgang(ITAR) ............................................................................................. 126
       11.3.8 Begrænsning af brugernes adgange(ITAR) ................................................................................................................ 126
       11.3.9 Stikprøvekontrol af systemloggen(ITAR) .................................................................................................................... 127
       11.3.10 Supplerende kontroller(ITAR) ..................................................................................................................................... 127
       11.3.11 Krav til ekstern kommunikation(ITAR) ........................................................................................................................ 127
       11.3.12 Selvbetjening via portal(ITAR) .................................................................................................................................... 127
       11.3.13 Overholdelse af sikkerhedsstanderder og -lovgivning(ITAR)...................................................................................... 128
   11.4 Test(ITAR) ........................................................................................................................................................................... 128
       11.4.1 Test i hht ATP_s testdisciplin(ITAR) ........................................................................................................................... 128
       11.4.2 Funktionel test(ITAR) ................................................................................................................................................. 128
       11.4.3 Grænsefladetest(ITAR) .............................................................................................................................................. 129
       11.4.4 ATPs testmanagementværktøj(ITAR) ........................................................................................................................ 129
       11.4.5 Leverancer(ITAR) ....................................................................................................................................................... 129
       11.4.6 Fejlhåndtering(ITAR) .................................................................................................................................................. 129
12     M IT-PRODUKTION(PRPL, PRTK) .......................................................................................................................................... 131
   12.1 Capacity management, kapacitetsstyring(PRPL/PRTK) ...................................................................................................... 133
       12.1.1 CAP1 Estimering af kapacitetstrækket(PRPL/PRTK) ................................................................................................. 133
       12.1.2 CAP2 Beregningsmodel for kapacitetstrækketPRPL/PRTK) ...................................................................................... 133


                                                                                                                                               Side I
    12.1.3 CAP3 Forventet kapacitetsudvikling(PRPL/PRTK) ..................................................................................................... 133
    12.1.4 CAP4 Procedure for performancetest og regressionstest(PRPL/PRTK) .................................................................... 133
    12.1.5 CAP5 Performancetest som fast element i testfaser(PRPL/PRTK) ............................................................................ 134
12.2 Accounting, forbrugsstyring(PRPL/PRTK) ........................................................................................................................... 134
    12.2.1 AC1 Accounting på systemet(PRPL/PRTK) ............................................................................................................... 134
    12.2.2 AC2 Forretningsområders forbrug af ressourcer(PRPL/PRTK) .................................................................................. 134
    12.2.3 AC3 Overførsel af opfølgningsdata til ERP-system(PRPL/PRTK) .............................................................................. 134
    12.2.4 AC4 Registrering af forbrug(PRPL/PRTK).................................................................................................................. 135
    12.2.5 AC5 Opfølgning på systemets oppe- og svartider(PRPL/PRTK) ................................................................................ 135
12.3 Problem management, problemhåndtering(PRPL/PRTK) .................................................................................................... 135
    12.3.1 PM1 Online adgang til problemmanagement(PRPL/PRTK) ....................................................................................... 135
    12.3.2 PM2 Leverandørens supportorganisation(PRPL/PRTK) ............................................................................................ 135
12.4 Document management, dokumenthåndtering(PRPL/PRTK) .............................................................................................. 136
    12.4.1 DOC1 Elektronisk arkivering af ind- og udgående dokumenter(PRPL/PRTK) ........................................................... 136
    12.4.2 DOC2 Central håndtering af layoustandarder m.v.(PRPL/PRTK) .............................................................................. 136
    12.4.3 DOC3 Udvikling af meget komplekse meddelelser(PRPL/PRTK) .............................................................................. 136
    12.4.4 DOC4 Effektiv støtte til enkeltmeddelelser(PRPL/PRTK) ........................................................................................... 136
    12.4.5 DOC5 Enkelt at tilrette tekster(PRPL/PRTK) .............................................................................................................. 137
    12.4.6 DOC6 Enkelt at tilrette tekster til enkeltmeddelelser(PRPL/PRTK) ............................................................................ 137
    12.4.7 DOC7 Billig af udføre opgaver(PRPL/PRTK) ............................................................................................................. 137
12.5 Out of Scope(PRPL/PRTK) .................................................................................................................................................. 137
    12.5.1 O1 Systemet kommer ikke ud af synkronisme(PRPL/PRTK) ..................................................................................... 137
    12.5.2 O2 Systemerne skal være selvafstemmende(PRPL/PRTK) ....................................................................................... 138
    12.5.3 O3 Håndtering af tunge brugerstartede kørsler(PRPL/PRTK) .................................................................................... 138
    12.5.4 O4 Datering af breve(PRPL/PRTK) ............................................................................................................................ 138
    12.5.5 O5 Online vedligeholdelse af centrale tabeller m.v.(PRPL/PRTK) ............................................................................. 138
    12.5.6 O6 Information til Internet brugere(PRPL/PRTK) ....................................................................................................... 139
    12.5.7 O7 Håndtering af logiske fejl(PRPL/PRTK) ................................................................................................................ 139
    12.5.8 O8 Afstemning mellem programmer og grænsefalder(PRPL/PRTK) ......................................................................... 139
    12.5.9 O9 Sandsynlighedskontroller i systemet(PRPL/PRTK) .............................................................................................. 139
    12.5.10   O10 Håndtering af redundante data(PRPL/PRTK) ................................................................................................ 140
    12.5.11 O11 Tilbagekaldelsesrutiner på elektroniske overførsler(PRPL/PRTK) ..................................................................... 140
    12.5.12   O12 Ikke samme dataleverance flere gange(PRPL/PRTK) ................................................................................... 140
    12.5.13   O13 Indlæsning af periodiske leverancer i rækkefølge(PRPL/PRTK) ................................................................... 140
    12.5.14   O14 Leverandørens referencer(PRPL/PRTK) ....................................................................................................... 140
    12.5.15   O15 Stop dataudveksling mellem grænseflader(PRPL/PRTK) .............................................................................. 141
    12.5.16   O16 Undgå specifik udsendelsesdato(PRPL/PRTK) ............................................................................................. 141
12.6 Generelt(PRPL/PRTK) ......................................................................................................................................................... 141
    12.6.1 G1 Placering af databaser i et databasehotel(PRPL/PRTK) ...................................................................................... 141
    12.6.2 G2 Databaser skal være platformuafhængige(PRPL/PRTK) ...................................................................................... 141
    12.6.3 G3 Understøttelse af virtuelplatform baseret på WM-ware(PRPL/PRTK) .................................................................. 142
    12.6.4 G4 Adskillelse af data og applikation(PRPL/PRTK) ................................................................................................... 142
    12.6.5 G5 Adskillelse af produktions- og test/udviklingsmiljø(PRPL/PRTK) .......................................................................... 142
    12.6.6 G6 Leverandøren har udelukkende adgang til testmiljø(PRPL/PRTK) ....................................................................... 142
    12.6.7 G7 Online vedligeholdelse af centrale tabeller m.v.(PRPL/PRTK) ............................................................................. 143
    12.6.8 G8 Procedure for performancetest og regressionstest(PRPL/PRTK) ......................................................................... 143
    12.6.9 G9 Performancetest som fast element i alle testfaser(PRPL/PRTK) .......................................................................... 143
    12.6.10   G10 Samarbejdsgrænseflade mellem leverandør og ATP(PRPL/PRTK) .............................................................. 143
    12.6.11 G11 Væsentlige succesfaktorer for leverance(PRPL/PRTK) ...................................................................................... 143
12.7 Change management, vedligeholdelsesstyring(PRPL/PRTK) ............................................................................................. 144
    12.7.1 CHMG1 Understøttelse af test-, pilot- og produktionsmiljøer(PRPL/PRTK) ............................................................... 144
    12.7.2 CHMG2 Gennemførelse af ændringer efter aftale(PRPL/PRTK) ............................................................................... 144
    12.7.3 CHMG3 Gennemførelse af ændringer i pakker(PRPL/PRTK) .................................................................................... 144
    12.7.4 CHMG4 Flytning mellem testmiljøer og pilot-/produktionsmiljøer(PRPL/PRTK) ......................................................... 144
    12.7.5 CHMG5 Leverandør i dialog med ATP(PRPL/PRTK) ................................................................................................. 145
    12.7.6 CHMG6 Lukning af systemet ifbm vedligehold(PRPL/PRTK) ..................................................................................... 145
    12.7.7 CHMG7 Overførsel af job-/ proces- defintioner fra test til produktion(PRPL/PRTK) ................................................... 145
    12.7.8 CHMG8 Ændring til databaser(PRPL/PRTK) ............................................................................................................. 145
    12.7.9 CHMG9 Leverancebeskrivelse(PRPL/PRTK) ............................................................................................................. 145
    12.7.10   CHMG10 Databaserettelser som DMLér(PRPL/PRTK) ......................................................................................... 146


                                                                                                                                     Side I
    12.7.11 CHMG11 Oplysningsfrist for opgraderinger(PRPL/PRTK) ......................................................................................... 146
    12.7.12    CHMG12 Oplysningsfrist for almindelig vedligehold(PRPL/PRTK) ........................................................................ 146
12.8 Configuration management, konfigurationsstyring(PRPL/PRTK) ......................................................................................... 146
    12.8.1 CFG1 Al dokumentation skal leveres i elektronisk(PRPL/PRTK) ............................................................................... 146
    12.8.2 CFG2 Ingen indtastning af variable ifbm job- og procesafvikling(PRPL/PRTK).......................................................... 147
    12.8.3 CFG3 Tegning over systemet(PRPL/PRTK) .............................................................................................................. 147
    12.8.4 CFG4 Dataflow for miljø(PRPL/PRTK) ....................................................................................................................... 147
    12.8.5 CFG5 Driftsdokumentation for miljø(PRPL/PRTK) ..................................................................................................... 147
    12.8.6 CFG6 Installationsvejledning(PRPL/PRTK)................................................................................................................ 148
    12.8.7 CFG7 Konfigurationsparamneter(PRPL/PRTK) ......................................................................................................... 148
    12.8.8 CFG8 Håndtering af alarmer og handlinger(PRPL/PRTK) ......................................................................................... 148
    12.8.9 CFG9 Beskrivelse af batch-job(PRPL/PRTK)............................................................................................................. 149
    12.8.10    CFG10 Identifikation af jobnavn(PRPL/PRTK) ...................................................................................................... 149
    12.8.11 CFG11 Navngivning skal være unik(PRPL/PRTK) ..................................................................................................... 149
    12.8.12    CFG12 Navngivning må ikke være begrænsende(PRPL/PRTK) ........................................................................... 149
    12.8.13    CFG13 Reorganisering mens systemet er online(PRPL/PRTK) ............................................................................ 150
    12.8.14    CFG14 Oplysninger om tidsafhængige hændelser(PRPL/PRTK) ......................................................................... 150
    12.8.15    CFG15 Sameksistens af batch- og online(PRPL/PRTK) ....................................................................................... 150
    12.8.16    CFG16 Processer skal kunne afvikles når somhelst(PRPL/PRTK) ....................................................................... 150
    12.8.17    CFG17 Distribution af klient-software via TNG SDO(PRPL/PRTK) ....................................................................... 151
    12.8.18    CFG18 Elektronisk behandling af output til brugere(PRPL/PRTK) ........................................................................ 151
    12.8.19    CFG19 Leverandørens hardware krav(PRPL/PRTK) ............................................................................................ 151
    12.8.20    CFG20 Leverandørens software krav(PRPL/PRTK) ............................................................................................. 151
    12.8.21    CFG21 Det infrastrukturmæssige vedligehold(PRPL/PRTK) ................................................................................. 151
    12.8.22    CFG22 Håndtering af fejl(PRPL/PRTK) ................................................................................................................. 152
12.9 Business management, forretningsoverblik(PRPL/PRTK) ................................................................................................... 152
    12.9.1 BM1 Levering af logisk tegning over miljø(PRPL/PRTK) ............................................................................................ 152
    12.9.2 BM2 Levering af legning over systemlandskabet(PRPL/PRTK) ................................................................................. 152
    12.9.3 BM3 Systemet kan indpasses i ATP miljø(PRPL/PRTK) ............................................................................................ 152
    12.9.4 BM4 Læseadgang til syslog/eventlog(PRPL/PRTK) ................................................................................................... 153
    12.9.5 BM5 Systemet er designet til 24 timers drift(PRPL/PRTK) ......................................................................................... 153
    12.9.6 BM6 Versions- og releasepolitik(PRPL/PRTK) ........................................................................................................... 153
12.10     Operation management, driftsstyring(PRPL/PRTK) ........................................................................................................ 153
    12.10.1    OM1 Business view til overvågningsmiljøet(PRPL/PRTK) ..................................................................................... 153
    12.10.2    OM2 Overvågning pr forretningsapplikation(PRPL/PRTK) .................................................................................... 154
    12.10.3    OM3 Nuanceret overvågning(PRPL/PRTK) ........................................................................................................... 154
    12.10.4    OM4 Automatisk inaktivering af fejlende komponenter (PRPL/PRTK) .................................................................. 154
    12.10.5    OM5 Leverandørens anbefaling(PRPL/PRTK) ...................................................................................................... 154
    12.10.6    OM6 Dokumentation af severity for hændelser(PRPL/PRTK) ............................................................................... 154
    12.10.7    OM7 Logning af hændelser(PRPL/PRTK) ............................................................................................................. 155
    12.10.8    OM8 System integereres til Tivoli overvågning(PRPL/PRTK) .............................................................................. 155
    12.10.9    OM9 Recovery håndterer automatisk data-recovery(PRPL/PRTK) ....................................................................... 155
    12.10.10 OM10 Online backupt(PRPL/PRTK) ...................................................................................................................... 155
    12.10.11 OM11 Checkpoint/restart(PRPL/PRTK)................................................................................................................. 155
    12.10.12 OM12 Automatisk roll-back foretages af transaktioner(PRPL/PRTK) .................................................................... 156
    12.10.13 OM13 Afviklingstid for batch-komponenter(PRPL/PRTK) ...................................................................................... 156
    12.10.14 OM14 Afvikling af årskørsler og adhoc-kørsler(PRPL/PRTK)................................................................................ 156
    12.10.15 OM15 Total system recovery(PRPL/PRTK) ........................................................................................................... 156
    12.10.16 OM16 Recovery af en mindre del af systemet(PRPL/PRTK) ................................................................................. 157
    12.10.17 OM17 Afvikling af backup efter frekvenser(PRPL/PRTK) ...................................................................................... 157
    12.10.18 OM18 Backup/restore(PRPL/PRTK)...................................................................................................................... 157
    12.10.19 OM19 Lukke brugere ud af systemet, mens det er kørende(PRPL/PRTK)............................................................ 157
    12.10.20 OM20 Overvågning på tekniske delkomponenter(PRPL/PRTK) ............................................................................ 157
    12.10.21 OM21 Batch-komponenter skifter døgn(PRPL/PRTK) ........................................................................................... 158
    12.10.22 OM22 Driftsdøgn afviger fra systemdøgn(PRPL/PRTK) ........................................................................................ 158
    12.10.23 OM23 Ingen tidsmæssige afhændigheder i systemet(PRPL/PRTK) ..................................................................... 158
    12.10.24 OM24 Initiering af processer/jobs(PRPL/PRTK) .................................................................................................... 158
    12.10.25 OM25 Returkoder til leverandøren(PRPL/PRTK) .................................................................................................. 159
    12.10.26 OM26 Automatiseret jobafvikling(PRPL/PRTK) ..................................................................................................... 159
    12.10.27 OM27 Log alle former for kommunikation(PRPL/PRTK) ........................................................................................ 159


                                                                                                                           Side I
12.10.28   OM28 Batch-komponenter genererer kørselslog(PRPL/PRTK) ............................................................................. 159
12.10.29   OM29 Sytemloggens indhold(PRPL/PRTK) .......................................................................................................... 159
12.10.30   OM30 Særlig alarm ved fejl i online opdateringer(PRPL/PRTK) ............................................................................ 160
12.10.31   OM31 Automatisk lukning af delsystemer(PRPL/PRTK) ....................................................................................... 160
12.10.32   OM32 Saneringsprogrammer(PRPL/PRTK) .......................................................................................................... 160
12.10.33   OM33 Stop dataudveksling mellem grænseflader(PRPL/PRTK) ........................................................................... 160
12.10.34   OM34 Hindring af igangsættelse af produktionskritiske kørsler(PRPL/PRTK) ....................................................... 161




                                                                                                                 Side I
                                                                                                                           15.12.2005




1        A TVÆRGÅENDE
    Visionskrav(TV)                          Generel funktionalitet(TV)                                                        Koncernkunder og Ydelseskatalog (TV)

             Standardsystem til flere                                                                                                  X - Ydelseskatalog(TV)
                                                   Datatilgængelighed på laveste         Noter(TV)
             juridiske enheder(TV)
                                                   niveau(TV)
                                                                                                                                       X - Oprettelse af
             Koncernkunde arbejder via
                                                    Brugeroplevet svartid(TV)            Totalintegration(TV)                          koncernkundeaftaler(TV)
             portal(TV)
                                                                                                                                       X - Kontrakt/drifts periode(TV)
             Time to market(TV)
                                                    Valutaneutralitet(TV)                Validering af data(TV)
                                                                                                                                       X - Afvikling af
              Ændring af parametre uden                                                                                                koncernkundeaftale(TV)
              programændring(TV)                    Kustodefunktioner (TV)               Udenlandske slutkunder(TV)
                                                                                                                                       X - Koncernkundernes
                                                                                                                                       adgang til data(TV)
                                                   Genbrug af funktioner på              Udenlandske
Klagehåndtering(TV)                                tværs af målgrupper(TV)               virksomheder(TV)                               X - Klikke tillægsfunktionalitet
                                                                                                                                        fra/til (TV)
                                                   Kunderådgiver agerer som              Tilbagerulning(TV)
        Håndtering af mundtlige klager(TV)                                                                                             X - Print af kundespecifik
                                                   slutkunde(TV)
                                                                                                                                       forretningsgang(TV)
        Håndtering af skriftlige klager og         Håndtering af fejl og                 Iværksættelser(TV)
        ankesager(TV)                              afvigelser(TV)
                                                                                                                               Tekniske og arkitektur krav(TV)

                                                  Genbrug af                             Anmeldelse til Datatilsynet(TV)
                                                                                                                                      Grænseflader(TV)
                                                  slutkundeinformationer(TV)

                                                   Samtykke på tværs af
                                                                                                                                      Skalerbarhed(TV)
                                                   ordninger(TV)


                                                                                                                                      Sanering af
                                                                                                                                      data/registreringer(TV)

                                                                                                                                      Single sign on(TV)


                                                                                                                                      Rollemodellen(TV)




                                                                            Figure 1 A TVÆRGÅENDE




1.1 Visionskrav(TV)



1.1.1         Standardsystem til flere juridiske enheder(TV)

Domæner/projekter: Alle.
Den tilbudte løsning skal primært være baseret på ét standardsystem, hvor det skal være muligt at definere en række juridiske enheder.
Omkostninger forbundet med oprettelse og nedlæggelse af selvstændige juridiske enheder skal kunne holdes på et minimum.
Alternativ Id : 01
Kravtype : Non-funktionelt
Kravstiller : Krav - RFI den : 2005 08 29
Status : Nyt       Prioritet :      Ansvarlig : Tværgående




                                                                                                                                        1
                                                                                          15.12.2005




1.1.2    Koncernkunde arbejder via portal(TV)

Systemet skal designes således, at koncernkunderne kan få mulighed for - via portalen - at arbejde
med de ydelser, de har købt, på lige fod med ATP's egne medarbejdere.

Alternativ Id : 02
Kravtype : Non-funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 08
Status : Nyt       Prioritet :  Ansvarlig : Portaler




1.1.3    Time to market(TV)

Domæner/projekter: Alle.
Systemet skal understøtte visionen om hurtigt og effektivt at kunne tilbyde opsætning af nye produkter og services for både
ATP samt nye og eksisterende koncernkunder - helt konkret skal:
     En ny koncernkunde kunne implementeres indenfor maximalt 6 mdr.
     Helt nye produkter indenfor 1-3 måneder.
     Ny funktionalitet til eksisterende produkter indenfor 1 uge - 1 måned.
Alternativ Id : 03
Kravtype : Non-funktionelt
Kravstiller : Krav-PIXI den : 2005 08 29
Status : Nyt       Prioritet :        Ansvarlig : Tværgående




1.1.4    Ændring af parametre uden programændring(TV)

Domæner/projekter: Alle.
ATP ønsker et system, der i høj grad er parameterstyret, således at alle generelle parametre kan ændres uden programændringer.
      Vedligeholdelse af parametre skal være brugervenlige, så de kan betjenes direkte af en 'superbruger'.
Alternativ Id : 04
Kravtype : Non-funktionelt
Kravstiller : SP den : 2005 08 29
Status : Nyt       Prioritet :      Ansvarlig : Tværgående




1.2 Klagehåndtering(TV)



1.2.1    Håndtering af mundtlige klager(TV)

Det skal kunne registreres særskilt på telefonresuméet, at medlemmet/arbejdsgiveren/eleven har
     klaget, således at der til brug for ekstern og intern rapportering kan laves udtræk over antallet af




                                                                                                      1
                                                                                               15.12.2005



        mundtlige klager, der bliver håndteret over telefonen. Endvidere skal telefonresumét også kunne
        trækkes med ud, så man kan se, hvad der er klaget over, og hvad vi har svaret. Det kan i den
        forbindelse overvejes, om der skal være flere 'koder' at registrere under, så klagerne grupperes
        afhængig af, hvad der klages over. Dermed er der mulighed for erfaringsopsamling.

Der skal være integration til DataWarehouse og der skal være entydig registrering af data i
     struktureret form (tvungne datafelter til kategorisering, behandling, rapportering mv.).
Alternativ Id : 05
Kravtype : Funktionelt
Kravstiller : Tværgående den : 2005 10 11
Status : Nyt       Prioritet :   Ansvarlig : Tværgående




1.2.2     Håndtering af skriftlige klager og ankesager(TV)

Skriftlige klager og ankesager.

Klagerne skal registreres særskilt i systemet, og det skal ske med særlige 'koder' el.lign., så der
    efterfølgende kan laves udtræk til ekstern og intern rapportering over antal og indhold af
    klagerne. For såvidt angår indholdet skal registreringen ske, så vi får et overblik over, hvad der
    klages over. Erfaringsopsamlingen skal bruges præventivt, så vi forhåbentlig kan nedsætte
    antallet af klager ved at forbedre de områder, hvor der klages hyppigt. Indsatsen kan fx ske ved
    at stramme op i breve, udvide rådgivningen eller ændre teksterne på internettet.

Herudover bør klageforløbet understøttes af workflow, således at det er muligt at styre sagerne rundt i
    systemet. Fx fra sagsbehandler til jurist og tilbage igen, eller fra sagsbehandler til chef.

Endelig bør der også være en pop up, oversigt el.lign., som automatisk kommer frem eller kan hentes
    frem, når medlemmet/arbejdsgiveren/eleven ringer, således at sagsbehandleren får et overblik
    over igangværende og/eller tidligere klager.

Kravbesvarelse:
Ankesager registreres i dag typisk i en i særskilt oversigt (word eller excel). Det kan overvejes i højere grad at systematisere dette.
      Umiddelbart det dog ikke sikkert, at en højere grad af systematisering nødvendigvis vil kræve en særlig systemunderstøttelse.

Ankesager bør blot være en speciel kategori af klagesager, der trigger et specielt workflow.


Alternativ Id : 06
Kravtype : Funktionelt
Kravstiller : Tværgående den : 2005 10 11
Status : Nyt       Prioritet :   Ansvarlig : Tværgående




1.3 Generel funktionalitet(TV)




                                                                                                            1
                                                                                             15.12.2005




1.3.1     Datatilgængelighed på laveste niveau(TV)

Domæner/projekter: Alle.
Alle domæner skal kunne stille deres data til rådighed på laveste niveau for Datawarehouse-domænet, inklusive en datamodel samt
       beskrivelse af de enkelte attributter og deres indbyrdes sammenhænge, værdiesæt mv.
Alternativ Id : 07
Kravtype : Non-funktionelt
Kravstiller : Krav-PIXI den : 2005 08 29
Status : Nyt       Prioritet :        Ansvarlig : Tværgående




1.3.2     Brugeroplevet svartid(TV)

Domæner/projekter: Alle/ingen (afventer ITAR).
Der stilles følgende krav til svartider på portalen:

Interne brugere
Indtastninger:
      Der må ikke være nogen forsinkelse mellen indtastninger på samme side.
      Der må ikke være nogen forsinkelse ved validering og efterfølgende fejlmeddelelse.

Navigation:
     Når brugeren trykker på Ok -knappen og skifter side må det maksimalt tage 0,5 sekund at vise næste side.
Igangsætning af opgaver:
     Når en bruger starter en opgave må det højst tage 0,5 sekund at vise første side. (Incl alle de oplysninger der måtte være
      relevante.

Rapporter:
    Det må maksimalt tage 1 sekund at vise en rapport


Eksterne brugere

Indtastninger:
      Der må ikke være nogen forsinkelse mellen indtastninger på samme side.
      Der må ikke være nogen forsinkelse ved validering og efterfølgende fejlmeddelelse.

Navigation:
     Når brugeren trykker på Ok -knappen og skifter side må det maksimalt tage 1 sekund at vise næste side.
Igangsætning af opgaver:
     Når en bruger starter en opgave må det højst tage 1 sekund at vise første side. (Incl alle de oplysninger der måtte være
      relevante.

Rapporter:
    Det må maksimalt tage 3 sekunder at vise en rapport

Alternativ Id : 08
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 09 30
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




                                                                                                           1
                                                                                               15.12.2005



1.3.3    Valutaneutralitet(TV)

Domæner/projekter: Interessent, Ind/ud, Kerne, Kundebogholderi.
Alle systemer der håndterer pengebeløb skal kunne modtage, udbetale og omregne i DKK og andre valutaer. Der skal ske på baggrund
af en parameteropsætning, hvor en ændring i valuta nemt og enkelt kan omstilles i alle relevante domæner.
Alternativ Id : 09
Kravtype : Funktionelt
Kravstiller : Use Case arbejde den : 2005 10 07
Status : Nyt       Prioritet :     Ansvarlig : Tværgående

Accept Kriterie :
Krav 1
Et system/program er valutaneutralt, når det kan fungere uafhængigt af om beløbene det håndterer er i danske kroner eller i EURO.

Krav 2
Samtidig må man aldrig være i tvivl om hvilken valuta et beløb er angivet i. Kommunikation med andre systemer skal indeholde
entydige beløbsangivelser.

Krav 3
Et program er ikke valutaneutralt hvis eksempelvis ordet 'Kroner' er hardkodet i programmet.

Deraf følger:
Der må ikke være beløbskonstanter (hardkodede konstanter) og ledetekster i programmerne, alle beløb og valutaangivelser skal hentes
i tabeller. Der skal være entydig relation mellem beløb og valuta, enten på tabelniveau eller ved at benytte en parametertabel hvor
gældende valuta hentes.

Valutaangivelse skal altid angives i servicen.
Af hensyn til konvertering til eksempelvis EURO skal alle beløbsfelter være med 4 decimaler i tabellen.

1.3.4    Kustodefunktioner (TV)

Domæner/projekter: Alle.
Alle domæner i NAFS systemlandskabet skal stille funktionalitet til rådighed til oprettelse, læsning, ændring og sletning af relevante
begreber/objekter (CRUD-funktioner - Create, Read, Update, Delete). Herunder også kustodefunktioner til administration og
vedligeholdelse af deres forretningsprocesser, samt regel- og parameterdata.

Der skal være rettighedsstyring på disse funktioner.


Alternativ Id : 10
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 08
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




1.3.5    Genbrug af funktioner på tværs af målgrupper(TV)

Domæner/projekter: Alle.
Den tilbudte løsning anvender størst mulig princippet om genbrug af funktioner på tværs af målgrupper (mellem privat- og
virksomhedskunder og mellem koncernkunder og medarbejdere). Dog skal der være mulighed for differentiering og
branding via parametre.

Alternativ Id : 11
Kravtype : Non-funktionelt




                                                                                                          1
                                                                                                 15.12.2005


Kravstiller : Krav-PIXI den : 2005 09 08
Status : Nyt       Prioritet :     Ansvarlig : Tværgående




1.3.6     Kunderådgiver agerer som slutkunde(TV)

Domæner/projekter: Portal, sikkerhed.
Alle webportal dialoger skal også kunne benyttes af kunderådgiver, såldes at kunderådgiveren kan anvende portalen på vegne af en
slutkunde, der fx henvender sig pr. telefon. Hændelsen skal logges/dokumenteres.
Alternativ Id : 119
Kravtype : Funktionelt
Kravstiller : Use Case arbejde den : 2005 09 26
Status : Nyt       Prioritet :       Ansvarlig : Portaler




1.3.7     Håndtering af fejl og afvigelser(TV)

Domæner/projekter: Alle.
Alle fejl og afvigelser opstået i automatiske processer skal rapporteres automatisk fx. via Workflow.
Alternativ Id : 13
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 09 12
Status : Nyt        Prioritet :        Ansvarlig : Interessent




1.3.8     Genbrug af slutkundeinformationer(TV)

Håndtering af informationer vedrørende slutkunder/personer) er reguleret af (bl.a.)
persondatalovgivningen og forvaltningslovens § 32, som bestemmer, at vi hver især kun må have
adgang til de oplysninger, som vi har et arbejdsmæssigt behov for at have adgang til.
ATP-lovens bestemmelser om tavshedspligt gør det ulovligt uberettiget at videregive oplysninger til
uvedkommende.

Eksterne samarbejdspartnere (koncernkunder)
Systemet skal (ved rolle-anvendelse) sikre at eksterne samarbejdspartnere kun får adgang til egne slutkunder, og at tilgængelige
informationer er begrænsede til de specifikke data da må se, jf. lovgivning, aftaler med CPR, SKAT mv, samt de eventuelle specifikke
oplysninger slutkunden har givet.
Det betyder bl.a. at koncernkunder ikke må få fuld adgang til CRM data, men kun må se henvendelser og informationer der er lagret i
forbindelse med rådgivning og sagsbehandling i forhold til deres produkter.

Interne medarbejdere
Overholdelse af bl.a. persondataloven, skal ske ved opbygning af roller (se TIM/TAM projektet) og skal derfor ikke implementeres i
(back-end) systemet. Som yderligere sikring skal instrukser (arbejdsgangsbeskrivelser) tydeligt beskrive hvorledes kundehåndteringen
skal foretages i de situationer, hvor forskelligt datagrundlag betyder at sagsgangen og/eller rådgivning divergerer. (Skal i øvrigt - så vidt
muligt - workflow understøttes)

Systemet skal tage udgangspunkt i, at der er én datamodel/informationsmodel som skal dække de samlede informationsbehov. For at
opfylde lovgivning, herunder persondatabeskyttelse, skal systemet tydeligt anføre hvis data er beskyttede, angive for hvilke
koncernkunder data kan anvendes, samt angive hvis data kun må anvendes i forbindelse med specifikke (navngivne)
'ordninger/produkter'.




                                                                                                               1
                                                                                               15.12.2005


På lignende vis skal systemet anføre om der er givet samtykke til at videregive oplysningerne, samt specificere hvilke (relevante)
ordninger der ikke er givet samtykke til.
Herefter er det op til den enkelte medarbejder samt dennes ansvarlige chef at sikre at de gældende regler iagttages under rådgivning
og sagsbehandling.

Særligt ved kundehåndtering for PensionService
I forbindelse med implementering af PensionService koncernkunder, skal konkurrenceretlige begrænsninger efterleves. De
konkurrenceretlige begrænsninger betyder at der kun i begrænset omfang må udleveres data til koncernens private ordninger da
udlevering vil stille ATP som administrator af de private ordninger bedre end administratorer af private ordninger udenfor koncernen.
Herunder skal det bemærkes at ATP og SKAT er undervejs med aftale om virksomhedsoplysninger til ATP hvori ATP vil få
mulighed for at viderelevere data til PensionService under forudsætning af, at det sker indenfor lovens rammer.

Krav bør verificeres som del af K&P beslutningspunkts-proces

Kilde til præciseringer:
K:\Projekter\NAFS\NAFS_Krav_- Løsning2Leverancer\Forretningsprincipper\BPR Referencedokument_190805.ppt
K:\Projekter\NAFS\NAFS-Løsning\Interessent\Juridisk afklaring interessent 20050124.doc
Alternativ Id : 14
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 08 30
Status : Nyt       Prioritet :    Ansvarlig : Interessent




1.3.9     Samtykke på tværs af ordninger(TV)

Med ref. til krav 14 ”Genbrug af slutkundeinformationer” skal der opbygges en ”Samtykke
registrerings funktion” der understøtter at slutkunderelaterede informationer kan deles og udveksles
på tværs af vores ordninger, således at ATP's interne arbejdsgange kan optimeres. Dette skal give
mulighed for at foretage sagsbehandlingen på tværs fx ved dødsfald eller alderspensionering.

Funktionen skal kunne håndtere samtykkeerklæringer, således at fx:
       To eller flere koncernkunder kan gennemtvinge en samtykke for deres respektive medlemmer
       Et medlem/en interessent kan vælge samtykke for/mellem alle relevante koncernkunder
       Et medlem/en interessent kan vælge samtykke for/mellem to eller flere koncernkunder
       Et medlem kan vælge samtykke på koncernkunder uden for vores administration
       En koncernkunde kan vælge at gennemtvinge samtykke for medlemmer med ekstern part.

Funktionalitet foreslås implementeret således at alle Koncernkunder står ens. Herefter implementeres specifikke (gældende) regler
hvilket betyder at der etableres samtykke mellem de regulerede ordninger osv.
Yderligere skal nedenstående implementeres:
      Det hvor der er en generel eller specifik lovhjemmel (eksempelvis indeholder CPR-loven en række bestemmelser om hvilke
          oplysninger Indenrigsministeriet kan videregive til private)
      Der er tale om oplysningerne, der i øvrigt er offentligt tilgængelige eller kan hentes hos andre fx SKAT, CPR, skifteretten osv.

Krav bør verificeres som del af K&P beslutningspunkts-proces
Alternativ Id : 21
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 08 23
Status : Nyt       Prioritet :    Ansvarlig : Interessent




                                                                                                            1
                                                                                                15.12.2005



1.3.10 Noter(TV)

Domæner/projekter: Workflow, DokH.
Noter (i form af en elektronisk post it) skal kunne tilføjes antal på alle aktiviteter(workflow), dokumenter og sager og samtidig stemples
med person og tidspunkt.

Disse noter skal kunne vises på et valgfrit tidspunkt i processen eller efterfølgende ved visning af f.eks en journal sagsmappen.

Ikke strukturerede data skal så vidt muligt gøres til strukturerede data, bl.a. ved brug af standard valgmuligheder.
Alternativ Id : 15
Kravtype : Funktionelt
Kravstiller : Dokumenthåndtering den : 2005 10 08
Status : Nyt       Prioritet :       Ansvarlig : Tværgående




1.3.11 Totalintegration(TV)

Domæner/projekter: Alle.
Der skal være fuld integration og gensidig understøttelse mellem de forskellige domæner i systemlandskabet. Det vil bla. sige, at alle
systemer skal kunne trigge hinanden.

Eksempler:
> Print trigger workflow.
> Journalisering trigger workflow.
> E-mail, call-center trigger workflow, CRM mv.
> CRM trigger workflow.
> Kerne trigger workflow.
> Workflow trigger print, eksterne systemer, kerne mv.
> ERP (HR) trigger workflow.
> Call center skal være fuldt workflow-understøttet.
> Alle dokumenter/hændelser mellem atp-koncernen og kunderne skal journaliseres uanset hvor de stammer fra.

Alternativ Id : 16
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 21
Status : Nyt       Prioritet :  Ansvarlig : Call Center




1.3.12 Validering af data(TV)

Domæner/projekter: a) Portal b) Alle.
Systemet skal foretage to typer af generelle valideringer:

a)Al inddatering skal underkastes validering og formatkontrol ved indgangen

b)Der skal foretages validering i det delsystem, der ejer de pågældende data og en omhyggelig tværgående validering ud fra det
samlede korpus af forretningsregler og forretningssammenhænge.
Et succeskriterium for at denne validering fungerer, er en yderst lav rate af problemer under den automatiske behandling, fx den
månedlige fremføring.
Alternativ Id : 17
Kravtype : Funktionelt
Kravstiller : Krav - Bilag 2 den : 2005 09 26
Status : Nyt       Prioritet :        Ansvarlig : Tværgående




                                                                                                              1
                                                                                             15.12.2005




1.3.13 Udenlandske slutkunder(TV)

Domæner/projekter: Interessent, Ind/Ud, Kerne.
Systemet skal forberedes til at kunne håndtere udenlandske slutkunder. Udenlandske slutkunder kan være 3. part, virksomheder,
organisationer og medlemmer.

Eksempel:
PensionsDenmark opkøber et Finsk pensionsselskab og derfor skal vi kunne håndtere interessenter uden dansk cprnr.
Alternativ Id : 18
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 09 20
Status : Nyt       Prioritet :    Ansvarlig : Interessent




1.3.14 Udenlandske virksomheder(TV)

Domæner/projekter: Interessent, Ind/Ud, Kerne.
Systemet skal forberedes til at kunne håndtere udenlandske virksomheder og koncernkunder.
Alternativ Id : 19
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 09 20
Status : Nyt       Prioritet :      Ansvarlig : Interessent




1.3.15 Tilbagerulning(TV)

Domæner/projekter: Alle.
Alle handlinger (transaktioner) foretaget skal kunne tilbagerulles ved kompenserende handlinger.
Alternativ Id : 20
Kravtype : Funktionelt
Kravstiller : Use Case arbejde den : 2005 09 26
Status : Nyt       Prioritet :        Ansvarlig : Tværgående




1.3.16 Iværksættelser(TV)

Systemet skal understøtte at iværksættelser initieres og gennemføres uden involvering af interne eller eksterne it-
ressourcer.

Iværksættelser skal kunne foretages på opfordring eller ved automatisk aktivering (defineret set-up). Iværksættelser skal kunne
foretages nemt og unden forestyrelse af kørende systemer.

Der ønskes bl.a. mulighed for at iværksætte:
    Portal/contentmanager; Content, tekstrettelser, pop-ups, kampagner, spørgeskemaer mv.
    Workflow; Ændringer i workflow og nye workflows, der tager udgangspunkt i eksisterende workflows [krav id 4, 5,
     17, 19, 29]




                                                                                                          1
                                                                             15.12.2005


       Dokumenthåndtering; brevrettelser [Krav id 623]
Alternativ Id : 36
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 19
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




1.3.17 Anmeldelse til Datatilsynet(TV)

I forbindelse med de konkrete koncernkundeimplementeringer skal det sikres at der foreligger de
korrekte (og lovlige) anmeldelser til Datatilsynet

Alternativ Id : 37
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 20
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




1.4 Koncernkunder og Ydelseskatalog (TV)



1.4.1     X - Ydelseskatalog(TV)

Det skal være muligt at se hvilken funktionalitet der implementeres ved salg af en ekstern ydelse (basis-,
proces- og tillægsydelser). D.v.s. hvilke skærmbilleder der benyttes og hvilken back-end funktionalitet der
understøtter ydelsen.

Det skal være muligt at se hvilke domæner, der indgår i de enkelte eksterne ydelser (basis-, proces-, og
tillægsydelser).
Alternativ Id : 31
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 19
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




1.4.2     X - Oprettelse af koncernkundeaftaler(TV)

Krav til systemunderstøttelse i forbindelse med etablering af koncernkunden efter kontrakten er på plads.
    Det skal være muligt at oprettelse koncernkunder, med angivelser af stamoplysninger; firmanavn,
         adresse, telefon, primære kontakter mv. (specifikke krav jf. informations- og datamodellen)
    Det skal være muligt at angive hvilke ydelser den enkelte koncernkunde har købt, samt 'flag' (indikation)
         hvis ydelsen kræver specialtilpasning
    Det skal være muligt, inden for de enkelte ydelser, at definere (opdele/beskrive) en til flere specifikke
         virksomhedsaftaler




                                                                                        1
                                                                                   15.12.2005


    Alternativ Id : 32
    Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 19
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




    1.4.3        X - Kontrakt/drifts periode(TV)

Krav til systemunderstøttelse i forbindelse med vedligeholdelse og ændringer til koncernkunde-kontrakten. I
perioden efter oprettelse og etablering.
Vedligeholdelse og ændring af koncernkundedata
     Mulighed for at ændre stamoplysninger
     Mulighed for at ændre i ydelser
     Mulighed for at kunne indtaste/logge oplysninger om koncernkundehenvendelser
     Mulighed for at opnå overblik over koncernkunderelationer med log over personrelationer, henvendelser,
         historik m.m.
     Mulighed for, inden for ydelsen, at ændre, tilføje eller fjerne specifikke virksomhedsaftaler
    Alternativ Id : 33
    Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 19
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




    1.4.4        X - Afvikling af koncernkundeaftale(TV)

Det skal være muligt at afvikle den enkelte koncernkunde uden at det berører de øvrige koncernkunder (f.eks.
skal koncernkunde B ikke genteste funktionalitet i forbindelse med at koncernkunde A's funktionalitet fjernes).

Alternativ Id : 34
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 19
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




1.4.5    X - Koncernkundernes adgang til data(TV)

Domæner/projekter: Portal.
Koncernkunderne skal have mulighed for at få den samme adgang til data vedrørende deres ydelser
og kunder som udvikles til ATP’s egne medarbejdere (både visning og opdatering).
Adgang til performance og øvrig rapportering afklares udenfor denne specifikation.
Alternativ Id : 25
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 15
Status : Nyt       Prioritet :  Ansvarlig : Portaler




                                                                                           1
                                                                                            15.12.2005



1.4.6    X - Klikke tillægsfunktionalitet fra/til (TV)

Domæner/projekter: ITAR.
I udviklingen skal der laves standardløsninger, der er brede nok til at dække kunderne, og hvor der er mulighed for at
”klikke” tillægsfunktionalitet fra eller til. Det giver en hurtig time to market og en standardisering, hvor koncernkunderne
fortsat har bevægelsesfrihed.
Alternativ Id : 27
Kravtype : Funktionelt
Kravstiller : Krav-PIXI den : 2005 09 16
Status : Nyt       Prioritet :     Ansvarlig : Tværgående




1.4.7    X - Print af kundespecifik forretningsgang(TV)

Det skal være muligt at udprinte en samlet kundespecifik forretningsgang på baggrund af instrukser/forretningsgang fra
portal og workflowssystem.
Udprintningen skal foregå brugervenligt og skal dække alle domæner.
Alternativ Id : 35
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 19
Status : Nyt       Prioritet :     Ansvarlig : Tværgående




1.5 Tekniske og arkitektur krav(TV)



1.5.1    Grænseflader(TV)

Domæner/projekter: Alle.
Alle grænseflader i arkitekturen og mellem domæner skal aftales med behøring involvering af relevante parter.



Alternativ Id : 28
Kravtype : Non-funktionelt
Kravstiller : Krav - Bilag 13 den : 2005 08 29
Status : Nyt       Prioritet :      Ansvarlig : Tværgående




1.5.2    Skalerbarhed(TV)

Domæner/projekter: Teknik.
Systemet skal kunne skaleres ved blot at addere ekstra kapacitet.
Alternativ Id : 29
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 08 29
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




                                                                                                         1
                                                                                                15.12.2005




1.5.3     Sanering af data/registreringer(TV)

Domæner/projekter: Alle.
Det skal være muligt ét sted at angive/parameterstyre hvor længe data skal gemmes til brug for alle domæner. Paramtrene for sletning
skal opdeles på henholdsvis virksomheds- og kundedata og på forskellige aftaletyper.

Det skal være muligt at have forskellige saneringsfrister pr. aftaletype f.eks krav, der støttes på et særligt retsgrundlag, (et gældsbrev
eller en dom) eller udbetaling af erstatning ved personskade/Invaliditet og kritisk sygdom.
Alternativ Id : 30
Kravtype : Funktionelt
Kravstiller : Use Case arbejde den : 2005 09 30
Status : Nyt       Prioritet :        Ansvarlig : Tværgående




1.5.4     Single sign on(TV)

Der skal være single sign-on mellem alle domæner for ATP-bruger eller koncern-/slutkunden.

Der skal ikke foretages særskilt signon til WF systemet for interne brugere, hverken ved design,
ledelse eller medarbejder anvendelse. Single signon skal anvendes, som foregår via
TIM/TAM/Webseal/LDAP i ATP.
Alternativ Id : 233
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 05
Status : Nyt      Prioritet :     Ansvarlig : Workflow




1.5.5     Rollemodellen(TV)

Rollemodellen skal implementeres centralt i forbindelse med (TIM/TAM), herunder skal
dataopdateringer til roller og "individers" tilknytning til disse etc. kunne foretages af superbrugere.
Effekten af de opdateringer skal slå igennem med det samme.

Rollemodellen skal omfatte ATP-brugere, koncern- og slutkunden (inkl. 3. part).
Alternativ Id : 38
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 20
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




                                                                                                              1
                                                                                                         15.12.2005




2       B PORTALER

Generel funktionalitet


            Visionskrav (Portal)
                                                                                   Sammenhængende brugergrænseflade(Portal)

            Fejltolerant brugerdialog(Portal)
                                                                                   Opkobling af selvbetjeningsapplikationer til eksterne
                                                                                   portaler(Portal)
            Navigation mellem skærm og data(Portal)
                                                                                   Genbrug af portlets(Portal)

            Effektiv brugerdialog(Portal)
                                                                                   Brow ser/styresystemer(Portal)

            Flere åbne applikationer samtidig(Portal)
                                                                                   Print(Portal)

            Online-hjælp(Portal)
                                                                                   Overholdelse af design- og strukturmanual(Portal)

            Menuer/funktioner og fejlbeskeder på dansk(Portal)                     Visuel kvittering(Portal)

            Webstatistikker(Portal)                                                Fælles portal med fælles struktur m.v(Portal)


            Portaltyper og portalfunktionalitet(Portal)                            Automatisk visning af dokumenter mv.(Portal)


            Andre kommunikationsmedier(Portal)


            Dybe links(Portal)


            Søgning(Portal)



Selvbetjeningsfunktionalitet

        Mulighed for at beregne diverse
    1   prognoser(Portal)

        Prognoseberegninger gemmes
    2   automatisk(Portal)

        Datafangst ved
    3   selvbetjeningsfunktionalitet(Portal)




                                                                 Figure 2 B PORTALER




                                                                                                                        1
                                                                                    15.12.2005




2.1 Selvbetjeningsfunktionalitet



2.1.1     Mulighed for at beregne diverse prognoser(Portal)

Mulighed for at beregne diverse prognoser for af forskellige scenarier baseret på dels historiske data
dels diverse variable, fx prognoser for pensionsudbetaling.

Konkrete krav specificeres i use cases.
Alternativ Id : 418
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Mulighed for at udarbejde diverse prognoser afhængig af ordning.

2.1.2     Prognoseberegninger gemmes automatisk(Portal)

Krav b:
Prognoseberegninger (scenarier) gemmes automatisk, så de kan genskabes af bruger.

Konkrete krav specificeres i use cases.
Alternativ Id : 419
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2     Ansvarlig : CRM

Accept Kriterie :
Prognoseberegninger skal kunne kaldes frem hvis nødvendigt.

2.1.3     Datafangst ved selvbetjeningsfunktionalitet(Portal)

Kunden kan selv rette sine visse af sine personlige data.

Konkrete krav specificeres i use cases.

Eksempler:
   email
   telefonnummer
   permission marketing
     samtykke
     reg.nr./kto.nr.
     trækprocent
     valgbillede for slutkunde.
Alternativ Id : 484
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05




                                                                                            1
                                                                                            15.12.2005


Status : Nyt        Prioritet : 3   Ansvarlig : CRM

Accept Kriterie :
Kunden får et medansvar for at opdatere sine oplysninger

2.2 Generel funktionalitet



2.2.1    Visionskrav (Portal)

Overordnede krav til Portalen:
     Det primære indgangspunkt for koncernkunder
     Alt hvad der vedrører slutkunderne skal ligge her
     Kunderne skal kunne det samme som ATP
     Kunderne skal informere/rådgive sig selv
Alternativ Id : 100
Kravtype : Non-funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 15
Status : Nyt      Prioritet :      Ansvarlig : Portaler




2.2.2    Fejltolerant brugerdialog(Portal)

Generelt skal brugerdialogen i systemet være fejltolerant, dvs. skal ved indlysende inputfejl eller
fejlbetjeninger kunne føre til det ønskede resultat uden eller med få korrigerende handlinger

Alternativ Id : 101
Kravtype : Non-funktionelt
Kravstiller : Krav - RFI den : 2005 08 28
Status : Nyt       Prioritet :     Ansvarlig : Portaler

Accept Kriterie :
Fejltolerant
• systemet skal komme med forslag til udbedring af indlysende inputfejl – de foreslåede input-værdier skal kunne ændres af brugeren

2.2.3    Navigation mellem skærm og data(Portal)

Brugeren skal have flere muligheder for at navigere mellem skærmbilleder og data. Hvor det kan lette
brugeren skal relevante data som f.eks. CPR-nummer og ordning (SP, LG) flyttes med over i det
næste billede.

Alternativ Id : 102
Kravtype : Non-funktionelt
Kravstiller : SP den : 2005 08 28
Status : Nyt      Prioritet :     Ansvarlig : Portaler

Accept Kriterie :
Navigation mellem skærm & data:




                                                                                                         1
                                                                                            15.12.2005


• Overførelse af stamdata/nøgler mellem skærmbilleder i relevante tilfælde
• Aldrig nødvendigt at indtaste samme stamoplysning/nøgle to gange i sammen dialog/opgave
• Automatisk visning af alle relevante eller allerede kendte oplysninger.

2.2.4      Effektiv brugerdialog(Portal)

Generelt skal brugerdialogen i systemet være velegnet til opgaven og tilgodese kravet om høj
effektivitet, primært så den meget rutinerede bruger kan være top effektiv, men sekundært også, så
den mindre rutinerede kan komme hurtigt og sikkert i gang.

Alternativ Id : 103
Kravtype : Non-funktionelt
Kravstiller : SP den : 2005 08 28
Status : Nyt      Prioritet :     Ansvarlig : Portaler

Accept Kriterie :
1) Brugerdialog velegnet til opgaven

Acceptkriterier:

• Opgave-afhængig funktionalitet er tilgængelig – så få steps som muligt
• Opgave-afhængig data og information stilles til rådighed fra start
• Dialogen er målrettet og opgavespecifik
• Opgave-afhængig online-hjælp er tilgængelig på rette sprog.
• Funktioner og skærmbilleder, som ikke er relevante for opgaveløsning er skjult for sagsbehandleren.

2) Effektiv brugerdialog til udførelse af opgaven

Acceptkriterier:

• Tidsforbrug (hvor langt tid tager det at udføre opgaver)
• Indtastningstid (hvor langt tid tager det at indtaste data)
• Navigationstid (hvor langt tid tager det at bladre mellem skærmbilleder)
• Antal skærmbilleder (hvor mange skærmbilleder skal sagsbehandleren igennem for at udføre en opgave – jo flere skærmbilleder jo
       mindre effektiv er dialogen)
• Data fremvisningstid (hvor lang tid tager det at vise data på skærmbilleder)
• Find funktioner (hvor langt tid tager det at finde de funktioner, der skal bruges til udførelse af opgaven
• Genvejstaster findes
• Kontekstafhængig hjælp gives
• Antal fejlmuligheder (hvor mange fejl laver sagsbehandleren under udførelse af opgaven – jo flere fejl jo mindre effektiv er
       brugerdialogen)
• Rækkefølge – I hvilken rækkefølge skal sagsbehandleren indtast data i de forskellige felter, navigerer frem og tilbage mellem
       skærmbilleder osv. Jo mere intuitiv og selvforklarende jo mere effektiv er dialogen)
• Målrettethed – dialogen skal løse denne specifikke opgave


2.2.5      Flere åbne applikationer samtidig(Portal)

Systemet skal kunne afvikles på brugeres klient, samtidigt med at andre applikationer, fx et office
        produkt, afvikles i andre vinduer på den samme klient.

Alternativ Id : 104
Kravtype : Non-funktionelt
Kravstiller : SP den : 2005 08 28
Status : Nyt      Prioritet :     Ansvarlig : Portaler




                                                                                                        1
                                                                                              15.12.2005




2.2.6    Online-hjælp(Portal)

Systemet skal være tilknyttet online-hjælp til skærmbilleder, felter og funktioner. Evt. skal hjælpen
    kunne tilpasses brugernes niveau. Der skal være mulighed for både fritekst- og indekseret
    søgning i online-hjælpen. Inddatering og ændring af online-hjælpen skal kunne foretages i ATP's
    egen organisation, samt i de organisationer, der har købt applikationer med on-line hjælp.

Første version af online-hjælpen skal leveres af leverandøren.

Hjælpen skal skelne mellem Interne og eksterne brugere og skal tilbydes på 3 niveauer:
    1. Applikationsniveau (eksterne brugere)
    2. Opgave-/sagsbehandlingsniveau(ATP's interne medarbejdere)
    3. Hjælp på feltniveau(ATP's interne medarbejdere)
Hjælpen på niveau 2 og 3 har karakter af rådgivning/instrukser til sagsbehandleren.
Et eksempel på rådgivningshjælp kunne være, at der ikke må betales dødsfaldsydelser til samlevers børn uden
dokumentation - eller at, dødsudbetalinger over 200.000 kr. skal godkendes af 2 sagsbehandlere.
Alternativ Id : 105
Kravtype : Funktionelt
Kravstiller : SP den : 2005 08 28
Status : Nyt      Prioritet :     Ansvarlig : Portaler

Accept Kriterie :
Online-hjælp
• Oline-hjælpen skal være på dansk.
• Opdeling af Online-hjælp i hurtig hjælp "Quick guide" og dybtgående hjælp.
• Kontektsrelateret hjælp skal være til stede. F.eks. hjælp ved modstridende feltværdier (en 20 årig som alderspensionist)
• Fritekst- og indekseret søgning i online-hjælpen.
• Løbende opdatering af Online-hjælpen foretages af leverandør.

Note: Tilpasning af hjælpen til brugerens niveau skal ikke kunne lade sig gøre, da det er dyrt at implementere og vedligeholde.
ATP skal ikke står for vedligeholdelsen af Online-hjælpen, fordi det er en tidskrævende opgave.

2.2.7    Menuer/funktioner og fejlbeskeder på dansk(Portal)

Sproget dansk skal være understøttet i alle menuer/funktioner og fejlbeskeder.
Det skal være muligt at undsrstøtte andre sprog også.
Alternativ Id : 106
Kravtype : Non-funktionelt
Kravstiller : Krav - RFI den : 2005 08 28
Status : Nyt       Prioritet :     Ansvarlig : Portaler




2.2.8    Webstatistikker(Portal)

Vi skal kunne lave standard webstatistik/navigationsanalyse/adfærdsanalyse på individniveau (hvem,
hvornår, hvor, hvor længe….).



                                                                                                           1
                                                                                              15.12.2005



Webstatistk skal også kunne undersøttes af eksterne værktøjer f.eks. Webtrends og Netminers, og
det skal integreres til datavarehus.
Alternativ Id : 107
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 09 15
Status : Nyt       Prioritet :    Ansvarlig : Portaler




2.2.9    Portaltyper og portalfunktionalitet(Portal)

Generelt
Ens for alle portaler (uanset mål gruppe - også medarbejderportal): Fælles struktur, fælles CMS-system (opdatering af indhold
internt/eksternt), fælles datakomponenter (til datatransport), mulighed for samkøring af data på tværs (betinget af samtykke), mulighed
for branding af selskab (logo, farver, opsætning indenfor frame, eget domæne mv.). Forfatterværktøj/CMS skal være standardsystem.
MON: Er besluttet og valgt.
Eksterne portaler skal tænkes ind f.eks. PensionsInfo (single signon), mulighed for betjeningsmoduler (3.part) og indhold fra
koncernkunde på andre sites (CMS).

WebContentManager (WCM) skal kunne anvendes i forskellige sammenhæng
Content mangageren skal implementeres således at forskellige sites kan nedarve funktionalitet og design. Det skal være
muligt at fravælge funktionalitet og design, dog kan det accepteres at der er generelle retningslinier som er std.
Generel design og funktionalitet må ikke være ATP-koncernens, da ATP-koncernen i denne sammenhæng er en kunde
på lige fod med de øvrige koncernkunder.
Det forudsættes at alle løsninger hostes/driftes under ATP's ansvar - dvs. sælges ikke til drift hos de enkelte
koncernkunder.

Medarbejderportal(medarbejdere i ATP, samt datterselskaber)
Redaktører skal kunne oprette menupunkter, faneblade og publicere indhold.
Der udvikles én fælles portal for medarbejdere i ATP koncernen og for medarbejdere hos koncernkunder. Branding er
ATP koncernens og styres centralt

Koncernkunders medarbejdere
ContentManageren skal kunne sælges og implementeres således at koncernkundernes medarbejdere kan få adgang til
den aftalte funktionalitet, og således at (eksterne og/eller interne) redaktører kan oprette menupunkter, faneblade og
publicere indhold.
Denne opsætning skal kunne tilpasses koncernkundes design, og krav til brugervenlighed/arbejdsmiljøkrav.

Slutkundeportaler(arbejdsgivere, lønmodtagere, skoler, elever og andre)
Til alle koncernkunder (i både det regulerede og deregulerede område) skal der kunne tilbydes en slutkundeportal,
eksempelvis atp.dk, fk,dk, joep.dk, hvor koncernkunden er redaktør på hjemmesiden og således kan oprette
menupunkter, faneblade og publicere indhold.

Ekstranet
Tilsvarende slutkundeportal, skal det være muligt at opsætte ekstranet til to relationstyper, hvor ekstranettet nedarver
funktionalitet fra 'ejeren'
Eksempel:
www. ekstranet .atp.dk - ATP's ekstranet mod koncernkunder og samarbejdspartnere. Sitet nedarver fra ejeren, dvs.
www.atp.dk
www. ekstranet.pd.dk - PensionDanmarks ekstranet mod deres samarbejdspartnere mv. Sitet nedarver fra
www.pensiondanmark.dk

Kravbesvarelse:




                                                                                                           1
                                                                                   15.12.2005


Generel design og funktionalitet må ikke være ATP-koncernens, da ATP-koncernen i denne sammenhæng er en kunde
på lige fod med de øvrige koncernkunder.
Det forudsættes at alle løsninger hostes/driftes under ATP's ansvar - dvs. sælges ikke til drift hos de enkelte
koncernkunder.
Bemærk. I forhold til krav skelnes ikke imellem hvor funktionalitet placeres. Nærværende krav er gældende uanset om
funktionalitet placeres i ContentManager, egenudviklet forfatterværktøj eller portal-værktøj.
Alternativ Id : 108
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 08 28
Status : Nyt       Prioritet :    Ansvarlig : Portaler




2.2.10 Andre kommunikationsmedier(Portal)

Portalen skal være forberedt til at håndtere andre kommunikationsmedier - eksempelvis: WAP, GPRS(General Packet
Radio Service ).

Specifikke krav skal udtrykkes i én use case pr. medie.
Alternativ Id : 109
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 09 06
Status : Nyt       Prioritet :    Ansvarlig : Portaler




2.2.11 Dybe links(Portal)

Det skal være muligt at generere dybe links ind i systemet, eksempelvis således at vi kan sende en e-
mail med link til en applikation, der så præsenterer sig med relevante data.

Alternativ Id : 110
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 06
Status : Nyt      Prioritet :   Ansvarlig : Portaler




2.2.12 Søgning(Portal)

Resultatet af en søgning på portalen skal opdeles på 2 nivauer:
   på dokument-niveau: viser en liste over relevante dokumenter - fx. feriepenge
   på applikations-niveau - her tilbydes en liste over selvbetjeningsmuligheder, der matcher det søgte ord fx
     "feriepenge".

   Alternativ Id : 111
   Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 09 08
Status : Nyt       Prioritet :    Ansvarlig : Portaler




                                                                                               1
                                                                                         15.12.2005



    2.2.13        Sammenhængende brugergrænseflade(Portal)

Brugergrænsefladen for rådgiveren skal fremstå som ét sammenhængende system, så rådgiveren ikke skal ”hoppe”
mellem forskellige skærmbilleder.

Alternativ Id : 112
Kravtype : Non-funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 08
Status : Nyt      Prioritet :   Ansvarlig : Portaler




2.2.14 Opkobling af selvbetjeningsapplikationer til eksterne portaler(Portal)

Alle (forretnings)applikationer skal designes så det er muligt at placere/tilgå dem på eksterne sites (fx.
som webservices) således at de indgår som del af site.

Visualisering af krav (eksempler):
     Virk.dk (indberetningsapplikation placeres på virk.dk, så arbejdsgivere kan indberette når de er der
     PensionsInfo. (beregningsapplikationer placeres her, så personer kan beregne konsekvens ved senere pensionering)
     3F (Se min sag placeres så fagforeningsmedlemmer kan følge deres sager på www.3f.dk)

Alternativ Id : 113
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 08
Status : Nyt      Prioritet :   Ansvarlig : Portaler




2.2.15 Genbrug af portlets(Portal)

Det skal være muligt at genbruge portlets på tværs af intranet/ekstranet/internet

Alternativ Id : 114
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 09 15
Status : Nyt       Prioritet :    Ansvarlig : Portaler




2.2.16 Browser/styresystemer(Portal)

Systemet skal kunne understøtte alle versioner af de nævnte browsere og operativsystemer op til 12
måneder tilbage i tiden.

Test og teknisk support på de enkelte versioner skal være understøttet overfor ATP-bruger, koncern-
og slutkunde.

Nedenstående krav er et øjebliksbillede, og bør opdateres en gang årligt.



                                                                                                     1
                                                                                      15.12.2005




Operativsystemer
Systemet skal kunne understøtte følgende operativsystemer:
Windows 98 eller nyere
MacOS X eller nyere
Linux
Browsere
       Windows
       ·      Microsoft Internet Explorer 5 eller nyere
       ·      Netscape Navigator 7 eller nyere
        Mozilla/Firefox 1.0 eller nyere

       Mac OS X
       ·     Netscape Navigator 7.1 eller nyere
       ·     Mozilla/Firefox eller nyere
       Linux
       ·     Netscape Navigator 6.2 eller nyere
       ·     Opera 7 eller nyere
       ·     Mozilla

Sikkerhed
       Af sikkerhedsmæssige årsager skal browser understøtte en 128 bit SSL-kryptering.

Andre samarbejdspartnere
Morningstar stiller krav til ATP om et system der kan levere en web-service (Microsoft Frameworks vers. 1.1).

Kravbesvarelse
Det er et krav til brugerens browser indstillinger, at JavaScripts og cookies skal være tilladte ved brug af licensgivers web-
applikationer.
Vi bør overveje at stille krav om min. ISDN/ADSL forbindelse på 128kbit i download.
Alternativ Id : 115
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 09 15
Status : Nyt       Prioritet :    Ansvarlig : Portaler




2.2.17 Print(Portal)

Det skal være muligt at udskrive indholdet af den aktive portlet ved etablering af en 'printvenlig'-
funktion.

Alternativ Id : 116
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 09 23
Status : Nyt       Prioritet :    Ansvarlig : Portaler




2.2.18 Overholdelse af design- og strukturmanual(Portal)

Portalerne skal opbygges efter guidelines angivet i atp's design- og strukturmanualer
(brugergrænseflader/portaler).



                                                                                                   1
                                                                                   15.12.2005




ATP koncernens design manualer skal overholdes i forhold til branding og sub-branding.

Der er 3 designmanualer:
     En grund manual, som skal overholdes af alle.
     En ”Ikke-ATP koncern manual
     En ATP-koncern manual

Alternativ Id : 117
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 09 29
Status : Nyt       Prioritet :    Ansvarlig : Portaler




2.2.19 Visuel kvittering(Portal)

Systemet kan præsentere brugeren for diverse visuelle bekræftelser - kvitteringer - når en given
interaktion er succesfuldt gennemført. Eksempelvis kunne kvitteres for 'Opdatering gennemført'.

Alternativ Id : 118
Kravtype : Funktionelt
Kravstiller : Use Case arbejde den : 2005 09 26
Status : Nyt      Prioritet :    Ansvarlig : Portaler




2.2.20 Fælles portal med fælles struktur m.v(Portal)

På Fælles-portalen skal der være fælles struktur, CMS-system og fælles datakomponenter – og
mulighed for samkøring af data mellem de forskellige ordninger (betinget af ordningers og Personers
samtykke samt registerlovgivningen)

Alternativ Id : 120
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 15
Status : Nyt      Prioritet :   Ansvarlig : Portaler




2.2.21 Automatisk visning af dokumenter mv.(Portal)

Det skal være muligt at konfigurere frontend/portal således at relevante dokumenter og øvrige sagsakter åbner automatisk
når rådgiveren åbner sag/svarer telefon mv.

Alternativ Id : 207
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                                              1
15.12.2005




        1
                                                                                                                                                          15.12.2005




3       C WORKFLOW
Generelt(WF)                                                                                               Brugergrænseflade/interface (WF)                        Opgavestyring/opfølgning(WF)

        Overordnede visioner/krav(WF)                   Tilgængelig information for                               Grafisk illustration af processer med                    X - Se belastningen på processer(WF)
                                                        aktiviteter(WF)                                           behandlingstider(WF)

        Sager/Processer relateres til flere             Tilgængelig information ved hver                          Brow ser baseret console(WF)                             Monitorering og flaskehalse(WF)
        juridiske enheder(WF)                           afsluttet proces(WF)

        Processer skal have et variable antal           Aktiviteter kan sorteres(WF)                              X - Workflow styring -ledelse- skal                      Monitorering foretages efter forskellige
        aktiviteter(WF)                                                                                           indgå som portlet(WF)                                    kriterier(WF)

        Alle data relateret til en sag fremstå i        Søgning på aktiviteter(WF)                                Indbakke skal indgå i portalen som                       Effektivitets måling(WF)
        seneste version(WF)                                                                                       portlet(WF)

        Tidsfrist og alarmer(WF)                                                                                                                                           Opsætte alarmering på servicemål(WF)


        Udføre parallel aktiviteter(WF)                 Aktivitet ikke automatisk gennemføres                                                                              Prioritering af aktiviteter(WF)
                                                        afsluttes(WF)

        Push/pull(WF)                                   Flytning af aktivitet uden om regler(WF)                                                                           X - Forventede ressourcetræk skal
                                                                                                                                                                           kunne beregnes(WF)
                                                                                                               Workflow s interaktion med andre systemer(WF)
        Migrere sager til andre medier(WF)              Aktiviteter kan tvinges til afslutning(WF)                                                                         Opgave/taskliste og portlets(WF)
                                                                                                                      Processer startes fra notifikationer (WF)

        Parameterstyrede forretningregler(WF)           Processer kan tvinges til afslutning(WF)                                                                           Tydeliggørelse at en alarm er
                                                                                                                                                                           overskrevet(WF)
                                                                                                                      Hent data fra WF og lagres i
                                                                                                                      journalsystemet(WF)
        Håndtere både strukturerede og                                                                                                                                     Administration/styring(WF)
        ustrukturerede flow s(WF)
                                                                                                                      Registrering i journalsystemet skal trigge
                                                                                                                      et WF(WF)
                                                                                                                                                                           Forretningsmæssig prioritering(WF)

                                                                                                                      Understøtte både synkrone og
                                                                                                                      asynkrone interaktioner(WF)                          Simulering(WF)


                                                                                                                                                                           Operationelle ledelse(WF)


Udvikling og vedligehold af forretningsgange(WF)                                                                                                                           Arbejdsredskab til opgavestyring(WF)


         Intuitiv grafisk interface for                                                                      Rapportering(WF)
                                                   Genbrug af processer på                                                                                                 Levere gennemsnit for opfølgning på
         designeren(WF)                            tværs(WF)
                                                                                                                      Online rapportering(WF)                              SLA(WF)

                                                   Identifikation af processer(WF)
                                                                                                                      X - Retrospektivt/tilbageskuende             Roller(WF)
                                                                                                                      billede(WF)
                                                   Identifikation af aktiviteter(WF)
                                                                                                                      Rapportering for returneret
         Allokerings Logik -                                                                                          aktivitet(WF)                                             Håndtere forskellige rolle
                                                   Design af processer som
         Parameter(WF)                                                                                                                                                          begreber(WF)
                                                   superbruger(WF)
                                                                                                                      Rapportering for aktiviteternes
         X - Rettelser i flow - og                                                                                    rækkefølge(WF)                                            Roller skal kunne defineres i TIM
                                                   Simulering og løbende
         allokeringslogik (WF)                                                                                                                                                  og anvendes i WF(WF)
                                                   ændringer(WF)
                                                                                                                      Operationel rapportering(WF)
                                                                                                                                                                                Skal kunne melde personer
                                                   Ændring af parameter on the
                                                                                                                                                                                ind/ud af en rolleliste(WF)
                                                   fly(WF)
                                                                                                                      X - Operationel rapportering-
         Aktivitets Definition understøtter        Proces Definition understøtte                                      forventet ressourceforbrug(WF)                            Medarbejder kan have flere
         forskellige status(WF)                    forskellige status(WF)                                                                                                       roller(WF)

         Aktivitets Instans understøtter
                                                   Proces Instans understøtter
         forskellige status(WF)
                                                   forskellige status(WF)
          Allokerings regler tilrettes af
                                                   Indsætte målepunkter(WF)
          teamleder(WF)




                                                                                                     Figure 3 C WORKFLOW




                                                                                                                                                                          1
                                                                                                15.12.2005




3.1 Generelt(WF)



3.1.1      Overordnede visioner/krav(WF)

       Effektiv udnyttelse af de til rådighed værende kompetencer og ressourcer. Det gælder både i forhold til normal belastning og
        spidsbelastning (dette betyder: opgaverne fordeles automatisk på baggrund af bl.a. prioritering af den pågældende opgaves og
        modtagers ”skills” - organisatorisk placering, rolle, praktik (kalendertid, sygdom) og kompetenceprofiler (eller aftaler fx i
        medarbejderudviklingen) (PIXI)

       Hurtige gennemløbstider på vores processer. (PIXI)

       Ensartet kvalitet i sagsbehandlingen. (PIXI)

       Bedst tænkelig støtte til sagsbehandlerne i deres arbejde. (PIXI)

       Det er et krav, at den tilbudte løsning skal gøre det lettere og hurtigere at indlægge ændringer i eksisterende forretningsgange
        eller indføre helt nye forretningsgange og dermed også helt nye koncernkunder. (PIXI)

       Implementere workflow, så det er forberedt til, at koncernkunder kan deltage i afviklingen af opgaverne og opbygge egne
        workflows til egne medarbejdere (PIXI)
       Work Flow skal spille effektivt sammen med andre parters sagsstyrings- og sagssystemer, herunder eventuelle Work Flow
        løsninger hos PS Kunder og Partnere. (RFI)

     Til ”alle” planlagte forretningsprocesser dækkende henvendelser i alle kanaler inklusive
     tidsstyrede forløb, ventetilstande
     Giver procesgennemsigtighed: operationelt, taktisk og strategisk
     Styrer igangsætning gennem strukturerede processer
      - af person use cases ved at åbne den/de rette portalsider (dvs. hvor personer benytter brugergrænseflader i
      forretningsapplikationer)
      - af automatiserede forløb hvor der kaldes services
      - men også til mere ad hoc brug af f.eks. Office-produkter f.eks. i en ansættelsesproces
      - og også af helt manuelle aktiviteter, hvor rollen kun tager og afslutter procesinstanser/aktiviteter, men ikke benytter anden IT-
      understøttelse
     Generelt kan samarbejde i organisationen endvidere understøttes af ad hoc workflows
      (”collaborative”/ ”unstructured”)
Alternativ Id : 223
Kravtype : Øvrig
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 02
Status : Nyt        Prioritet :       Ansvarlig : Workflow




3.1.2      Sager/Processer relateres til flere juridiske enheder(WF)

Sager/processer/aktiviteter skal kunne relateres til adskilte juridiske enheder

Alternativ Id : 201
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 08 31




                                                                                                              1
                                                                         15.12.2005


Status : Nyt    Prioritet :      Ansvarlig : Workflow




3.1.3    Processer skal have et variable antal aktiviteter(WF)

Processer skal kunne have et variabelt antal aktiviteter

Alternativ Id : 202
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.4    Alle data relateret til en sag fremstå i seneste version(WF)

Alle data som er relateret til en sag skal altid fremstå i den seneste udgave relateret til sagen

Alternativ Id : 203
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.5    Tidsfrist og alarmer(WF)

Der skal kunne sættes og tilrettes tidsfrist alarmer på både aktiviteter og processer

Alternativ Id : 204
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.6    Udføre parallel aktiviteter(WF)

Der skal kunne udføre parallel aktiviteter i en proces - dvs. mulighed for parallelhandlinger og
efterfølgende afventning og sammenknytning af resultater med bestemmelse af følgende aktiviteter.

Alternativ Id : 205
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                                   1
                                                                                       15.12.2005



3.1.7    Push/pull(WF)

Systemet skal understøtte både 'push' og 'pull' ved tildeling af sager til kunderådgiver.

Push: Sagen skubbes (pushes) ud til kunderådgiverens indbakke
Pull: Kunderådgiver skal selv tage en sag fra en indbakke

Alternativ Id : 206
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.8    Migrere sager til andre medier(WF)

Det skal være muligt at migrere sager til andre medier for at opbygge historik. Sagerne skal let kunne
fremsøges.

Alternativ Id : 208
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 05
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.9    Parameterstyrede forretningregler(WF)

Forretningregler, såsom beløbsgrænserne o.lign., skal være angivet som parametre.

Alternativ Id : 210
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 09 13
Status : Nyt       Prioritet :    Ansvarlig : Workflow




3.1.10 Håndtere både strukturerede og ustrukturerede flows(WF)

Både strukturerede og ustrukturerede flows skal kunne håndteres.

Et struktureret flow har en på forhånd fastlagt struktur, og kan være både it-understøttet og manuelt.

Et ustruktureret flow er ikke på forhånd lagt fast og vil normalt ikke være it-understøttet. Kunne fx
være en form for debat/vurdering om en sag mellem kolleger.
Alternativ Id : 211
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                                               1
                                                                        15.12.2005




3.1.11 Tilgængelig information for aktiviteter(WF)

For hver aktivitet skal en række information være tilgængelig.

Eksempelvis - igangsatte aktiviteter
- Hvem løser aktiviteten (brugerid/organisatoriske enhed)
- Hvornår blev aktiviteten taget
- Hvilken status har aktiviteten
- Hvor lang tid har aktiviteten været i gang

Eksempelvis - afsluttede aktiviteter
- Hvilke WF er aktiviteten en del af
- Hvem har afsluttet aktiviteten (bruger eller auto)
- Hvornår blev aktiviteten igangsat
- Hvornår blev aktiviteten afsluttet
- Hvem er kunden (cpr nr/cvr nr)
Alternativ Id : 214
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.12 Tilgængelig information ved hver afsluttet proces(WF)

For hver afsluttet proces skal en række information være tilgængelig.

Eksempelvis:
- Hvem afsluttet WF (brugerid/auto)
- Hvornår blev WF'en igangsat
- Hvornår blev WF'en afsluttet
- Hvad er WF gennemløbstid
- Hvad er den effektiv arbjedstid
- Hvad er samlede ventetid
- om forventede gennemløbstid er overholdt
- om forventede ressource anvendelse på opgaven er overholdt
- Hvilke kompetencer var nødvendige for at løse opgaven
Alternativ Id : 213
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                                1
                                                                         15.12.2005



3.1.13 Aktiviteter kan sorteres(WF)

Aktiviteterne skal sorteres efter forskellige kriterier

Alternativ Id : 216
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.14 Søgning på aktiviteter(WF)

Søgning efter aktiviteter og synliggørelse af, hvor en sag befinder sig skal være intuitiv

Alternativ Id : 217
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.15 Aktivitet ikke automatisk gennemføres afsluttes(WF)

Hvis en aktivitet ikke automatisk kan gennemføres/afsluttes opstartes et nyt workflow

Alternativ Id : 219
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.16 Flytning af aktivitet uden om regler(WF)

En aktivitet, som er i en medarbejders sagsbakke, skal kunne flyttes til en anden af både "ledelse" og
medarbejderen selv "uden om regler".

Handlingen skal dokumenteres/logges.
Alternativ Id : 220
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.17 Aktiviteter kan tvinges til afslutning(WF)




                                                                                   1
                                                                   15.12.2005



Aktiviteter skal kunne tvinges til afslutning (uden om regler).

Handlingen skal dokumenteres/logges.
Alternativ Id : 221
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.1.18 Processer kan tvinges til afslutning(WF)

Processer skal kunne tvinges til afslutning (uden om regler).

Handlingen skal dokumenteres/logges.
Alternativ Id : 222
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2 Udvikling og vedligehold af forretningsgange(WF)



3.2.1    Intuitiv grafisk interface for designeren(WF)

Der skal være et intuitiv grafisk interface for designeren

Alternativ Id : 266
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.2    Allokerings Logik - Parameter(WF)

Allokeringslogik skal kunne håndtere parameter f.eks kompetencer

Alternativ Id : 268
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 08 30
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                           1
                                                                                    15.12.2005



3.2.3    X - Rettelser i flow- og allokeringslogik (WF)

95% af alle rettelser til flowlogik skal kunne rettes, testes og iværksættes af workflowdesigneren. Der skal være et
iværksættelses-workflow der sikrer at implementering kan foretages af forretningsressourcer døgnet rundt - on the fly.

Alternativ Id : 224
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 08 30
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.4    Aktivitets Definition understøtter forskellige status(WF)

En aktivitetets definition skal understøtte forskellige status f.eks. Produktion, Simulering, Under
udarbejdelse, Deployed, Annulleret

Alternativ Id : 271
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.5    Aktivitets Instans understøtter forskellige status(WF)

En aktivitets instans skal understøtte forskellige status f.eks Aktiv, Inaktiv, Suspenderet, Termineret,
Afsluttet

Alternativ Id : 272
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.6    Allokerings regler tilrettes af teamleder(WF)

Allokerings regler herunder kompetencer (hvilke aktiviteter/processer m.v.en bestemt rolle skal kunne
håndtere på basis af enten deres kompetence eller rolle) skal kunne tilrettes inden for ½ time af f.eks
en teamleder eller andre forretnings ansvarlige

Alternativ Id : 273
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                                                1
                                                                      15.12.2005



3.2.7    Genbrug af processer på tværs(WF)

Det skal være muligt at genbruge allerede implementerede processer i nye workflows - fx.
genbrug/kopiering af en kampagneproces.

Alternativ Id : 274
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 08 31
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.8    Identifikation af processer(WF)

Processer skal kunne identificeres ved en række data oplysninger.

Kravbesvarelse
Se Info model for disse oplysninger.
Oplysninger på en proces instans kan være:

- ProcesInstansIdentifikation
- ProcesStatus
- ProcesStartDato
- ProcesStarttidspunkt
- ProcesSlutdato
- ProcesSluttidspunkt
- ProcesPrioritet
- ProcesTidsfristUdløbsdato
- ProcesTidsfrist

Alternativ Id : 275
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 08 31
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.9    Identifikation af aktiviteter(WF)

Aktiviteter skal kunne identificeres ved en række data oplysninger.

Kravbesvarelse
Se Info model for disse oplysninger:
Oplysninger der identificerer en aktivitet er f.eks.

- AktivitetInstansidentifikation




                                                                              1
                                                                    15.12.2005



- AktivitetEjer
- AktivitetStatus
- AktivitetStartDato
- AktivitetStarttidspunkt
- AktivitetSlutdato
- AktivitetSluttidspunkt
- AktivitetPrioritet
- AktivitetTidsfrist
- AktivitetTidsfristUdløbsdato
- AktivitetErindring
- AktivitetErindringUdløbsdato
Alternativ Id : 275
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 08 31
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.10 Design af processer som superbruger(WF)

Designeren som kan være en superbruger eller en øvet bruger eller en flowudvikler skal kunne
modellere processer og aktiviteter i et let forståeligt bruger interface

Alternativ Id : 277
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.11 Simulering og løbende ændringer(WF)

Designeren skal kunne simulere og viewe både processer og aktiviteter og løbende foretage
ændringer.

Alternativ Id : 278
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.12 Ændring af parameter on the fly(WF)

Ændring i f.eks parameter/regler til flows og implementering af de pågældende flows skal kunne
gøres on the fly (max et kvarter) - Ændring skal kunne slå igennem hele systemet, hvor parameter
anvendes.




                                                                              1
                                                                       15.12.2005


Alternativ Id : 279
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.13 Proces Definition understøtte forskellige status(WF)

En proces definition skal kunne understøtte forskellige status f.eks Produktion, Simulering, Under
udarbejdelse, Deployed, Annulleret

Alternativ Id : 280
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.14 Proces Instans understøtter forskellige status(WF)

En proces instans skal kunne understøtte forskellige status f.eks Startet
Afsluttet, Termineret, Kørende, Aktive, Suspenderet
Alternativ Id : 281
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.2.15 Indsætte målepunkter(WF)

Det skal være muligt at indsætte målepunkter i design af processen og det skal nedarves til den
"endelige proces"

Alternativ Id : 282
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.3 Brugergrænseflade/interface (WF)



3.3.1    Grafisk illustration af processer med behandlingstider(WF)




                                                                                1
                                                                        15.12.2005



Opbyggede Workflow med processer og aktiviteter skal kunne grafisk illustreres og det skal være
muligt at se behandlingstider. Øvrige oplysninger skal kunne fremvises ved "drill down"

Alternativ Id : 228
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.3.2    Browser baseret console(WF)

Der skal være en browser baseret console med aktuel status på produktivitet, workload,
målopfyldelse.

Alternativ Id : 229
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.3.3    X - Workflow styring -ledelse- skal indgå som portlet(WF)

Klienten til Workflow Styring ( Ledelse) skal indgå i Portalen som en portlet

Alternativ Id : 230
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.3.4    Indbakke skal indgå i portalen som portlet(WF)

Indbakke/task list m.v. skal indgå i Portalen som en portlet

Alternativ Id : 231
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.4 Workflows interaktion med andre systemer(WF)




                                                                                1
                                                                      15.12.2005



3.4.1    Processer startes fra notifikationer (WF)

Workflow processer skal kunne startes udefra events/notifikationer fra andre domæner

Alternativ Id : 235
Kravtype : Non-funktionelt
Kravstiller : Workflow den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.4.2    Hent data fra WF og lagres i journalsystemet(WF)

Der skal kunne hentes f.eks.aktivitetsstatus fra WF systemet og lagres i journalsystemet.

Alternativ Id : 238
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.4.3    Registrering i journalsystemet skal trigge et WF(WF)

Ved registrering i journalsystemet skal der automatisk kunne dannes et WF

Alternativ Id : 239
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.4.4    Understøtte både synkrone og asynkrone interaktioner(WF)

WF skal understøtte både synkrone og asynkrone interaktioner

Alternativ Id : 240
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.5 Rapportering(WF)




                                                                                1
                                                                                                15.12.2005



3.5.1     Online rapportering(WF)

Online rapportering skal kunne udstilles via en portlet som kan vises hvor som helst i portalen

Alternativ Id : 241
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 08 30
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.5.2     X - Retrospektivt/tilbageskuende billede(WF)

Chefen skal bruge Workflow til at skabe sig et retrospektivt/tilbageskuende billede af produktivitet i
forretningen. Det skal ske i ét billede og på et operationelt, taktisk og strategisk plan.
Der skal eksistere kun én grænseflade (læs skærmbillede) mellem Workflow og Datawarehouse. Workflowet føder data til
Datawarehouse og leverer et øjeblikkeligt billede eller et her og nu billede til chefen. Data der skal præsenteres for chefen eller
brugeren skal være transparent dvs., at man ikke behøver at vide, hvor data stammer fra.

Alternativ Id : 242
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 09 13
Status : Nyt       Prioritet :    Ansvarlig : Workflow




3.5.3     Rapportering for returneret aktivitet(WF)

Rapportering: For en rolle som har allokeret en aktivitet skal det være muligt at følge op på om en
rolle sender en uløst aktivitet retur til den fælles indbakke eller til en anden rolle

Alternativ Id : 243
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 29
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.5.4     Rapportering for aktiviteternes rækkefølge(WF)

Rapportering: Det skal være muligt at følge op på om en rolle tager aktiviteterne i den rækkefølge
som den forretningsmæssige prioritering foreskriver.

Alternativ Id : 244
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 29
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                                                              1
                                                                        15.12.2005



3.5.5    Operationel rapportering(WF)

Operationelle rapportering: Workflow skal kunne præsentere et her og nu (online) overblik over
samtlige aktive processer/aktiviteter som skal løses opstillet i en forretningsmæssige prioriteret
rækkefølge (den vigtigste øverst).

Alternativ Id : 245
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 29
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.5.6    X - Operationel rapportering- forventet ressourceforbrug(WF)

Operationelle rapportering: Med udgangspunkt i de aktive sager skal det være muligt, at beregne det
forventede ressourcebehov totalt og pr. rolle/kompetence. Det skal være muligt for førstelinjelederen
at angive hvor mange sager som skal medtages i beregningen (eksempelvis kun alle sager med
prioritet GUL).

Alternativ Id : 246
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 29
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6 Opgavestyring/opfølgning(WF)



3.6.1    X - Se belastningen på processer(WF)

Ledelse skal hele tiden kunne se belastningen på WF processerne, både detaljeret og i grafisk form.
Drill down benyttes til uddybende analyser.

Alternativ Id : 247
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.2    Monitorering og flaskehalse(WF)

Ledelse skal ved at anvende monitoreringen let kunne vurdere, hvordan evt. flaskehalse kan/skal
afhjælpes og gennemføre ændringen, evt. med at design'er ændrer WF.



                                                                                  1
                                                                       15.12.2005




Alternativ Id : 248
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.3    Monitorering foretages efter forskellige kriterier(WF)

Monitorering skal kunne foretages efter forskellige kriterier på summariske processer og aktiviteter.
Kriterierne kan variere. ( Overblik)

Alternativ Id : 249
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.4    Effektivitets måling(WF)

Effektivitets måling skal kunne håndteres

Alternativ Id : 250
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.5    Opsætte alarmering på servicemål(WF)

Der skal være mulighed for at opsætte alarmer, hvis et servicemål (fx fra SLA'en) ikke overholdes.

Alternativ Id : 251
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.6    Prioritering af aktiviteter(WF)

Der skal være mulighed fir at fremvise aktiviteter i prioriteret rækkefølge overfor kunderådgiveren.
Prioriteringsregler kan fx fastlægges udfra SLA-parametre.

Alternativ Id : 283
Kravtype : Funktionelt




                                                                                  1
                                                                      15.12.2005


Kravstiller : Krav - Workshop den : 2005 10 19
Status : Nyt       Prioritet :    Ansvarlig : Tværgående




3.6.7    X - Forventede ressourcetræk skal kunne beregnes(WF)

Det forventede ressourcetræk skal kunne håndteres

Alternativ Id : 252
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.8    Opgave/taskliste og portlets(WF)

Opgave-/taskliste og udsøgt opgave skal kunne ses på samme portal side / portlets.

Alternativ Id : 254
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.9    Tydeliggørelse at en alarm er overskrevet(WF)

Det skal tydeligt fremgå af alarmerne at en frist er overskredet samtidig med at man skal kunne se at
der er taget aktion og hvornår ny opfølgningsdato er identificeret.

Alternativ Id : 255
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.10 Administration/styring(WF)

Administration/styring: Det skal være muligt, at "tvinge" allerede allokerede aktiviteter fra den
personlige indbakke tilbage i den fælles indbakke (eksempelvis med et fast interval - hver midnat)

Alternativ Id : 256
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 29
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                                1
                                                                          15.12.2005




3.6.11 Forretningsmæssig prioritering(WF)

Forretningsmæssige prioritering: Der er behov for en model som kan håndtere multidimensionelle
mål/krav (a la balance scorecard). Eksempler på elementer kan være Type af proces, Type af
aktivtet, Kompleksistet, koncernkunde/SLA etc., Hvor lang tid har processen/aktiviteten ventet?. Vær
opmærksom på at denne liste ikke er udtømmende.

Alternativ Id : 257
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 29
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.12 Simulering(WF)

Produktet skal have faciliteter for simulering. Simulering skal være en integreret del af applikation som
giver mulighed for at simulere flows med forskellige parameter kriterier fra f.eks SLA

Alternativ Id : 258
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 08 30
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.13 Operationelle ledelse(WF)

Produktet skal have online og realtids faciliteter for måling og styring af effektivitet (Operationelle
Ledelse)

Alternativ Id : 259
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 08 30
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.6.14 Arbejdsredskab til opgavestyring(WF)

Produktet skal kunne anvendes som arbejdsredskab til opgavestyring for forskellige roller

Alternativ Id : 260
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 08 30
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                                     1
                                                                      15.12.2005




3.6.15 Levere gennemsnit for opfølgning på SLA(WF)

Produktet skal kunne levere gennemsnit normtid pr. proces/aktivitet så det muliggører opfølgning på
SLA/forventet afslutningstidspunkt

Alternativ Id : 261
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.7 Roller(WF)



3.7.1    Håndtere forskellige rolle begreber(WF)

Produktet skal kunne håndtere forskellige rolle begreber.

Alternativ Id : 262
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.7.2    Roller skal kunne defineres i TIM og anvendes i WF(WF)

Roller skal kunne defineres i TIM og provisioneres til TAM/LDAP, som skal kunne anvendes af
Workflow systemet direkte ved håndtering af indbakker og adgange for opslag

Alternativ Id : 263
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 05
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.7.3    Skal kunne melde personer ind/ud af en rolleliste(WF)

Det skal være nemt at melde en person ind/ud af en rolleliste for at tilpasse sagsbehandlere /
kompetencer - Ansvarsfordeling mellem ERP/SIKA og WF

Alternativ Id : 264
Kravtype : Funktionelt




                                                                                 1
                                                         15.12.2005


Kravstiller : Workflow den : 2005 09 05
Status : Nyt      Prioritet :     Ansvarlig : Workflow




3.7.4    Medarbejder kan have flere roller(WF)

En medarbejder kan have flere roller

Alternativ Id : 265
Kravtype : Funktionelt
Kravstiller : Workflow den : 2005 09 02
Status : Nyt      Prioritet :     Ansvarlig : Workflow




                                                                 1
                                                                                    15.12.2005




4       D INTERESSENT

 Interessent


         Automatisk sagsbehandlingsforløb(INT)                       Interessenter som objekter(INT)


         Adskillelse af data fra offentlige registre
                                                                     Mulighed for outsourcing(INT)
         og atps egne data(INT)

         Modtagelse af data fra ASK(INT)
                                                                     Flere SE-nr. knyttet til en virksomhed(INT)


         Administration af elektroniske
                                                                     Søgning på interessent(INT)
         postadresser(INT)

         Kontakttyper/hierarki på
         virksomhedsniveau(INT)

         Håndtering af forældre/barn relationer(INT)


         Oversigt over ordningernes adgang til
         interessentdata(CRM)



                                                  Figure 4 D INTERESSENT




4.1 Interessent



4.1.1    Automatisk sagsbehandlingsforløb(INT)

Systemet skal behandle og registrere alle relevante statusskifte på interessenter, og det videre
sagsbehandlingsforløb skal startes og fortsættes automatisk.



                                                                                               1
                                                                                        15.12.2005




Det skal være muligt at tilføje nye statuselementer (triggere) uden væsentlig systemudvikling.
Kravbesvarelse:

Det er vigtigt i denne sammenhæng, at de juridiske krav overholdes.

PERSON (CPR)
Når det er en person identificeret vha cprn. gives der meddelelse om:
     død og genoplivning,
     omnummerering og sletning af dobbeltnr,
     ændring af CPR-status anden end død og genoplivning
     ændring af statsborgerretskode
     annullering af CPRnr
     ændring af civilstand

VIRKSOMHED
Når det er en arbejdsgiver identificeret vha CVR/SENR anvendes et
abonnementssystem(VIRK), der indeholder triggere for hver handling, der er sket.
Der kan dannes følgende triggere, men en trigger dannes kun, hvis der er en abonnent:
Værdisæt: for trigger:

740001 = Ændret virksomhed
740002 = Ny virksomhed
740003 = Ændring i CVRnr.

740101 = Ændring af navn fra ToldSkat

740201 = Ændring af adresse og evt. teleoplysning fra ToldSkat
740202 = Ændring af adresse og evt. teleoplysning fra ATP

740301 = Ændring af teleoplysning fra ToldSkat
740302 = Alle tlf fra ToldSkat er slettet
740303 = Ændring af emailadresse fra ToldSkat
740304 = Alle email fra ToldSkat er slettet

740401 = Ændret driftsform
740402 = Ny udenlandsk arbejdsgiver

740501 = Ændrede myndighedsforhold

740601 = Ændrede brancheforhold

740701 = Ændrede ejerforholdsoplysninger
740702 = Nye ejerforholdsoplysninger
740703 = Ændrede lederoplysninger
740704 = Nye lederoplysninger
740705 = Alle ejere er slettet
740706 = Alle ledere er slettet

740801 = Ændret virksomhedsstatus
740802 = Ny virksomhedsstatus
740803 = Alle virksomhedsstati er slettet

740901 = Ændret registreringsstatus

741001 = Ny ATP-periode
741002 = ATP-slutdato ændret eller slettet
741003 = ATP-periode slettet af TS




                                                                                                1
                                                                                   15.12.2005


741004 = Ny ATP-virksomhed (dvs. minus pligten før)
741005 = ATP-slutdato er oprettet
741006 = Al ATP-pligt er slettet
741015 = Send ATP's ATP-perioder til ES
741016 = ATP-periode slettet af ATP
741017 = ATP-start ændret af ATP

741051 = Ny A-skatte-periode modtaget fra TS
741052 = A-skatte-pligt-slutdato ændret eller slettet
741053 = A-skatte-pligt-periode slettet
741054 = Ny A-skatte-virksomhed (dvs. har ikke haft pligten før)
741055 = Ny A-skatte-pligt slutdato oprettet
741056 = Al A-skatte-pligt er slettet

741061 = Ny moms-periode modtaget fra TS
741062 = Moms-pligt-slutdato ændret eller slettet
741063 = Moms-pligt-periode slettet
741064 = Ny moms-virksomhed (dvs. har ikke haft pligten før)
741065 = Ny moms-pligt slutdato oprettet
741066 = Al moms-pligt er slettet

741071 = Ny lønsums-periode modtaget fra TS
741072 = Lønsums-pligt-slutdato ændret eller slettet
741073 = Lønsums-pligt-periode slettet
741074 = Ny lønsums-virksomhed (dvs. har ikke haft pligten før)
741075 = Ny lønsums-pligt slutdato oprettet
741076 = Al lønsums-pligt er slettet

741201 = Ændringer i henvisninger
741202 = Ny henvisning
741203 = Alle henvisninger fra ToldSkat er slettet

741501 = Ændringer i registreringsforholdshenvisninger
741502 = Ny registreringsforholdshenvisning
741503 = Alle registreringsforholdshenvisninger fra ToldSkat er slettet

741301 = Ændring af persons dødsmarkering
741302 = Ny dødsmarkering
741303 = Alle dødsmarkeringer er slettet

741401 = Ændring af persons skattepligt
741402 = Ny personlig skattepligt
741403 = Alle personens skattepligter er slettet

741901 = Ændrede ligningsmarkeringsoplysninger
741902 = Ny ligningsmarkering
741903 = Alle ligningsmarkeringer er slettet


Alternativ Id : 300
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 08 23
Status : Nyt      Prioritet :   Ansvarlig : Interessent




4.1.2     Adskillelse af data fra offentlige registre og atps egne data(INT)




                                                                                           1
                                                                       15.12.2005



Oplysninger fra offentlige registre skal ikke kunne ændres.

I stedet skal der være "gældende oplysninger", hvor det er muligt at foretage redigering/ændringer.
     På den måde sikres det at der ikke manipuleres med oplysninger tilsendt.

Eksempelvis skal det være muligt at angive en ”gældende” adresse som er forskellig fra den adresse
    der registreret hos folkeregistret.

Udbetaling ved dødsfald sker kun via registrering via CPR-registreret. Mulighed for ved udbetaling til
terminal-patienter eller ved særlige tilfælde (katastrofer) som ”gældende oplysninger”.

Borteblevende registreres som døde hos CPR-registreret, når lovkrav er opfyldt.
Alternativ Id : 301
Kravtype : Funktionelt
Kravstiller : Use Case arbejde den : 2005 09 26
Status : Nyt      Prioritet :    Ansvarlig : Interessent




4.1.3      Modtagelse af data fra ASK(INT)

Systemet skal kunne modtage data fra ASK/Førtidspensionister elektronisk. Fx kunne man anvende
elektronisk kommunikation med Arbejdsskadestyrelsens EASY-system (standard web-service).


Alternativ Id : 302
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 08 30
Status : Nyt       Prioritet :    Ansvarlig : Interessent




4.1.4      Administration af elektroniske postadresser(INT)

Systemet skal kunne holde og administrere oplysninger om interessenters tilmelding til elektroniske
postadresser - fx E-boks.

Oplysningerne skal struktureres, så der er mulighed for at afspejle tilmeldingsniveau:
       Alle forsendelser tilmeldt
       Gruppe af forsendelser tilmeldt
       Enkelte forsendelser tilmeldt

Systemet skal kunne stille data til rådighed for relevante domæner.
Alternativ Id : 303
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 08 30
Status : Nyt       Prioritet :        Ansvarlig : Interessent




                                                                                  1
                                                                                         15.12.2005



4.1.5    Kontakttyper/hierarki på virksomhedsniveau(INT)

Der skal være mulighed for at oprette flere typer af kontakter [funktion, kontaktområde (dvs.
organisatorisk placering), etc] per virksomhed.

Eksempel på typer af kontakter:
     Enkeltperson
     Team/gruppe
     Sektion
     Afdeling
     Direktionsområde
     Uspecifik person (incl dennes titel)
     Sammensæt selv gruppe
Koncernkunden skal have mulighed for at se sine egne relationer (kontakttyper).
Alternativ Id : 304
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 08 23
Status : Nyt      Prioritet :      Ansvarlig : Interessent




4.1.6    Håndtering af forældre/barn relationer(INT)

Forældre/barn relationer skal kunne dokumenteres i systemet. Relationen oprettes og bruges i
    forbindelse med udbetaling af dødfaldsydelser. Der skal holdes styr på hvilke børn (stedbørn,
    samlevers børn, egne børn), der skal udbetales til.

Oplysninger om forældre/barn relationer skal være tilgængelige for alle domæner/systemer, derfor
    skal oplysningerne administreres centralt.
Men her skal man være særlig opmærksom på de juridiske krav, der er forbundet med genbrug af
    interessentdata på tværs af domæner/systemer.



Kravbesvarelse:
Registrering af forældre/barn relationer kommer for alle andre end ATP til at foregå manuelt.
Børneoplysninger skal registreres pr. ordning.
I PensionService udbetales dødfaldsydelser til stedbørn eller samleverbørn mod fremvisning af
     dokumentation (f.eks. bopælsadresse, dåbsattest m.fl.). Ligeledes holder atp-
     udbetalingssystemet styr på forhold mellem forældre og børn.


De juridiske krav kan også hentes her:
K:\Projekter\NAFS\NAFS-Løsning\Interessent\Juridisk afklaring interessent 20050124.doc


Alternativ Id : 305
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 08 23




                                                                                                 1
                                                                      15.12.2005


Status : Nyt     Prioritet :      Ansvarlig : Interessent




4.1.7    Oversigt over ordningernes adgang til interessentdata(CRM)

Systemet skal gøre det muligt at generere et oversigt over hvilken ordning har adgang til hvilke
interessentdata.

Alternativ Id : 306
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 07
Status : Nyt       Prioritet :    Ansvarlig : Interessent




4.1.8    Interessenter som objekter(INT)

Interessenter(personer, samarbejdspartnere, myndigheder) skal arkitektur- eller designmæssigt
     bygges som objekter med sammenhængende data og man skal kunne trække alle oplysninger
     ud på et givet objekt, eksempelvis alle oplysninger, kontaktoplysninger, adresser, telefonnumre,
     (hændelser) med CVR eller CPR som nøgle.

Alternativ Id : 307
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 08 30
Status : Nyt       Prioritet :    Ansvarlig : Interessent




4.1.9    Mulighed for outsourcing(INT)

Interessent-domænet skal designes med mulighed for outsourcing for øje.
Outsourcingen skal kunne ske pr. interessenttype (virksomhed, personer m.fl. )eller pr. leverandør.
Outsourcingen i denne sammenhæng betyder at få direkte elektronisk adgang til at læse/hente
interessentdata fra eksempelvis offentlige registre (cpr, virk etc).

Grænsefladen mellem Interessentdomænet og de øvrige domæner, skal kunne holde de øvrige
komponenter i systemlandskabet invariante overfor en ændring i Interessentdomænet. Fx. må en
udskiftning af den nuværende CPR funktionalitet med en offentlig Webservice kun kræve et lille
indgreb i Interessentdomænet, mens grænsefladen til de øvrige komponenter i det samlede
systemlandskab skal kunne fortsat være uberørt.

Alternativ Id : 308
Kravtype : Non-funktionelt
Kravstiller : Krav - Workshop den : 2005 08 30
Status : Nyt       Prioritet :    Ansvarlig : Interessent




                                                                                1
                                                                                   15.12.2005




4.1.10 Flere SE-nr. knyttet til en virksomhed(INT)

Relationen mellem 2 eller flere SE-nr. fra en virksomhed skal oprettes og vedligeholdes. F.eks. i AER
kan en arbejdsgiver betale sit bidrag på et SE-nr. og får udbetbaling på et andet SE-nr - da
indbetaling af AER-bidraget er en vigtig forudsætning for udbetaling er det vigtigt at systemet holder
styr på forholdet mellem SE-nr.




Alternativ Id : 309
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 08 23
Status : Nyt      Prioritet :   Ansvarlig : Interessent




4.1.11 Søgning på interessent(INT)

Der skal være gode søgefaciliteter på alle primære nøgler f.eks: CPR; CVR, SE-nr, navn (fonetisk).

• Søgeresultat skal præsenteres på en overskuelig og printvenlig måde.
• Brugeren skal have mulighed for at sortere søgeresultat
• Brugeren skal have mulighed for at bladre i søgeresultatet.
Alternativ Id : 310
Kravtype : Non-funktionelt
Kravstiller : Krav - RFI den : 2005 08 29
Status : Nyt       Prioritet :     Ansvarlig : Tværgående




                                                                                           1
                                                                                                                                                                                                                 15.12.2005




5             F CRM
 Forretning(CRM)                                                                                                                                               Marketing(CRM)                                                                                 Analytisk CRM


     Kun én brugerflade(CRM)                  Info til identifikation(CRM)              Registrering af kanalvalg(CRM)    Forretningens øvrige krav(CRM)             Kundeindsigt(CRM)                           Effektmåling(CRM)
                                                                                                                                                                                                                                                                    Data(CRM)
         Adgang til alle relevante                Identifikation af relevante
     2                                        1                                                                                                                          X - Analyse af persondata(CRM)              X - Effektmåling(CRM)
         oplysninger(CRM)                         informationer(CRM)                                                                                                 1                                           2                                                      Informartionsbærende data i
         Så få niveauer i systemet som            X - Identifikation af kunde(CRM)          X - Registrering af kundens                                                                                                                                             1   analysemart(CRM)
     2   muligt(CRM)                          1                                         1   ønsker(CRM)                                                                  Analyse af stamdata(CRM)
                                                                                                                                                                                                                 Responsregistrering(CRM)
                                                                                                                                                                     1                                                                                                  Opsamling af kundens kanalvalg(CRM
         Opdatering i 360-graders-billedet.       Info om hvor i en proces bruger                                                                                                                                                                                   1
     2   (CRM)                                3                                                                                                                          X - Analyse af holdningsdata(CRM)
                                                  befinder sig(CRM)                                                                                                                                                  X - Registrering af
                                                                                                                                                                     1
                                                                                                                                                                                                                 1   kampagnerespons(CRM)
                                                                                                                                                                                                                     X - Registrering af kunderettede
                                                                                                                                                                                                                                                                        Kategorisere kundehenvendelser(CRM)
         Alle ordninger i 360-graders                                                                                         X - Automatisk information til                                                     1   aktviteter mv.(CRM)
     2                                                                                                                                                                                                                                                              1
         billedet(CRM)                                                                                                    1   kunderådgiver/slutkunde(CRM)               X - Analyse af kontaktdata(CRM)             X - Rapportering af
                                                                                                                                                                     1                                                                                                  X - Resultater fra spørgeskemaerne ind i
         Ordningsspecifikke info fremgå af                                                                                    Ændring af info på 360 grader                                                      2   kampagnerespons(CRM)
     2                                                                                                                    1                                                                                                                                         2   en analysemart(CRM)
         360-grader (CRM)                                                                                                     billede(CRM)                               X - Analyse af IT-understøttelse(CRM)
                                                                                                                                                                     1
                                                                                                                                                                                                                 Målgruppeudvælgelse(CRM)
                                              Oversigt over kunderelaterede                                                                                                                                                                                         Støttefunktioner(CRM)
                                              transaktioner(CRM)                                                                                                     Samtykke(CRM)
         Mulighed for at skifte mellem
     2                                                                                                                                                                                                                X - Identifikation af målgrupper(CRM)
         ordninger(CRM)                           Log over ind- og udgående                                                                                                                                                                                             X - Resultat fra analytisk CRM ind i 360
                                              1                                                                                                                                                                  1
                                                  kundetransaktioner(CRM)                                                                                                Visning af samtykke i 360-graders                                                          1   graders billede(CRM)
         Vis info på tværs af
     2                                                                                                                                                               1   billede(CRM)
         kundegrupper(CRM)                                                              Samtaletid(CRM)                                                                                                               X - Udvælgelse af målgrupper(CRM)
                                                                                                                                                                                                                                                                        X - Håndtering af spørgeskemaer(CRM)
                                                                                                                                                                                                                 1
     Automatisk åbning af 360 graders                                                                                                                               Segmentering(CRM)                                                                               2
     billede(CRM)                                 Lister over transakt. indeholder          Samtaletid for aktive                                                                                                     X - Kampagneregistrering for
                                              1                                         2                                                                                                                        1                                                      X - Vedligeholdelse af
                                                  relevant info(CRM)                        kundesamtaler(CRM)                                                                                                        målgruppe(CRM)
                                                                                                                                                                         Udtræk ordningsspecifikkke data(CRM)                                                       2   spørgeskemaer(CRM)
                                                  Lister over transakt. med links til                                                                               1                                            Hændelsesbaseret kommunikation(CRM)
                                              1                                                                                                                                                                                                                         X - Driften af spørgeskemaer(CRM)
         360-graders billedet viser               relevant info(CRM)                                                                                                                                                                                                2
                                                                                                                                                                         X - Segmentering på relevante
     1   relevant info(CRM)                                                                                                                                         1
                                                  Mulighed for let at sortere og        Virksomhedskunde-specifikkke                                                     data(CRM)
                                              1   filtrere listen(CRM)                  krav(CRM)
                                                                                                                                                                         X - Segmentering på
                                                                                                                                                                    1    kampagnedata(CRM)                           X - Regelstyring for kunderettet
                                                                                                                                                                                                                 2                                                      Datafangst ved
     Søgenøgle(CRM)                                                                                                                                                                                                  kommunikation(CRM)
                                                                                                                                                                                                                                                                    3   selvbetjeningsfunktionalitet(Portal)
                                                                                                                                                                    Intern markedsføring(CRM)
                                                  Bruger og registrering af                 Se overenskomst-
                                              1   kundekorrespond.(CRM)                 1                                                                                                                            X - CRM på w ebben(CRM)
         Nyt CPR/SE-nummer skal kunne                                                       oplysninger(CRM)
     1   indtastes direkte(CRM)                                                                                                                                          X - Integration af kampagnemodul(CRM)
                                                  Seneste 3 transaktioner på 360            Se renteoplysninger på 360
                                              1                                                                                                                     2
                                                  graders billedet(CRM)                 1   grader(CRM)
                                                                                                                                                                    FAQ-lister(CRM)


                                                                                                                                                                         FAQ-lister(CRM)
                                                                                                                                                                    2




                                                                                                                                          Figure 5 F CRM




5.1 Forretning(CRM)



5.1.1                    Adgang til alle relevante oplysninger(CRM)

Krav a:
Adgang til alle relevante oplysninger fra 360-graders oversigtsbilledet og niveau(er) herunder.
Alternativ Id : 400
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Brugervenligt; hurtig kundebetjening.
Bruger skal kunne nøjes med at arbejde i ét program (med ét login) (lige nu kan 360-graders billedet stort set kun bruges til at hente
oplysninger fra og ikke til at ændre i).

5.1.2                   Så få niveauer i systemet som muligt(CRM)

Krav b:



                                                                                                                                                                                                                                                        1
                                                                                               15.12.2005



Så få niveauer i systemet som muligt; adgang til alle relevante informationer ét niveau under
selve 360-graders billedet.

Alternativ Id : 401
Kravtype : Non-funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Brugervenligt; hurtig kundebetjening.
Bruger skal kunne nøjes med at arbejde i ét program (med ét login) (lige nu kan 360-graders billedet stort set kun bruges til at hente
oplysninger fra og ikke til at ændre i).

5.1.3    Opdatering i 360-graders-billedet. (CRM)

Krav c:
Mulighed for at ændre/opdatere direkte i 360-graders-billedet.

Alternativ Id : 402
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Brugervenligt; hurtig kundebetjening.
Bruger skal kunne nøjes med at arbejde i ét program (med ét login) (lige nu kan 360-graders billedet stort set kun bruges til at hente
oplysninger fra og ikke til at ændre i).

5.1.4    Alle ordninger i 360-graders billedet(CRM)

Krav e:
Alle ordninger skal kunne indgå i 360-graders-billedet.
Alternativ Id : 404
Kravtype : Non-funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Adgang til info om alle ordninger i 360-grader, så bruger kan nøjes med at kende samt arbejde i et program.

5.1.5    Ordningsspecifikke info fremgå af 360-grader (CRM)

Krav f:
Ordningsspecifikke informationer skal fremgå af 360-grader for de forskellige ordninger.
Herunder også de informationer, som der oftest er behov for i de enkelte ordninger.
Alternativ Id : 405
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Relevante oplysninger skal være tilgængelige på forsidebilledet af 360-grader for de forskellige ordninger.




                                                                                                              1
                                                                                               15.12.2005



5.1.6     Mulighed for at skifte mellem ordninger(CRM)

Krav h:
Mulighed for nemt og hurtigt at skifte mellem de forskellige ordninger, fx vha. faneblade el.
rullemenu.
Alternativ Id : 407
Kravtype : Non-funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Kunne skifte mellem ordninger på en nem og hurtig måde, så der kan rådgives mm. på tværs af ordninger.

5.1.7     Vis info på tværs af kundegrupper(CRM)

Krav i:
Systemet skal kunne vise information om en persons data på tværs af kundegrupper /person- og
virksomhedskunde. Fx hvis en kunde er både arbejdsgiver og lønmodtager skal det fremgå tydeligt.
Informationer skal også vises på tværs ved samtykke f.eks. ydelser ved dødsfald og
alderspensionering for samlet sagsbehandling.
Alternativ Id : 408
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Når en person indgår i flere kundegrupper, skal det fremgå, så der kan rådgives mm. på tværs af ordninger.

5.1.8     360-graders billedet viser relevant info(CRM)

Krav b:
360-graders-billedet viser relevant information for det pågældende opkald.

Eksempel1: Hvis kunden ringer på kædenummeret for Pension DK, vises de informationer på 360-grader, der er relevante for
kundebetjening af Pension DK
Eksempel 2: Hvis kunden ringer på et kampagnenummer, vises de informationer, som er relevante ifbm. kampagnen.

Udvalgte data - f.eks. tidligere henvendelser (tidspunkt, emne og medie) - bør altid fremgå.
Alternativ Id : 410
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt       Prioritet : 1      Ansvarlig : CRM

Accept Kriterie :
Målrettet kundebetjening

5.1.9     Nyt CPR/SE-nummer skal kunne indtastes direkte(CRM)

Krav a:
Nyt CPR/SE-nummer skal kunne indtastes direkte fra oversigtsbilledet (så man ikke som nu skal
tilbage til indgangsbilledet for at indtaste en ny kundes CPR-nummer).



                                                                                                         1
                                                                                               15.12.2005


Alternativ Id : 412
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Hurtig kundebetjening - hurtigt skift mellem kunder

5.1.10 Identifikation af relevante informationer(CRM)

Krav a:
Identifikation af relevante informationer (mht. fx ordning (tydeligt logo), kundens CPR/SE-nr., navn) for
bruger.
Alternativ Id : 415
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Give overblik for bruger, som hele tiden let skal kunne identificere ordning, person/virksomhed osv..

5.1.11 X - Identifikation af kunde(CRM)

Krav b:
Identifikation af kunde (registrere og vise hvilke forskellige segmenter en kunde deltager i).
Alternativ Id : 416
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Opdeling /gruppering af kunder i segmenter.

5.1.12 Info om hvor i en proces bruger befinder sig(CRM)

Krav c:
Info om hvor i en proces bruger befinder sig og vejledning til bruger om, hvad næste step er (ved
integration til workflow).
Alternativ Id : 417
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 3  Ansvarlig : CRM

Accept Kriterie :
Bruger kan identificere hvor langt vedkommende er i behandling af en proces, og hvad næste skridt er.

5.1.13 Log over ind- og udgående kundetransaktioner(CRM)

Krav a:
Log over samtlige ind- og udgående kunderelaterede transaktioner indeholdende de nyeste




                                                                                                        1
                                                                                           15.12.2005



transaktioner i faldende rækkefølge - både for den enkelte ordning og på tværs af ordninger. Fx kan
den inddeles i henholdsvis korrespondance (brev-, telefon-mail) og ind-/udbetaling
Alternativ Id : 420
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Bruger skal kunne se alle tidligere (historiske) transaktioner relateret til kunden
- fx inddelt i hhv. ind/-udbetaling og korrespondance (herunder også print).

5.1.14 Lister over transakt. indeholder relevant info(CRM)

Krav b:
Listerne over transaktioner skal indeholde relevant info relateret til transaktionen (for ind-/udbetaling fx
transaktionstidspunkt, betalingsform (kontooverførsel, herunder kontonummer benyttet; check m.v.)).
Alternativ Id : 422
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Mulighed for at se (forskellige typer af) alle relevante informationer tilknyttet enkelte transaktioner.

5.1.15 Lister over transakt. med links til relevant info(CRM)

Krav c:
Listen over transaktioner skal være tilknyttet links til relevant info, fx breve, notater mv. som har relation til transaktionen.
Alternativ Id : 423
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Mulighed for let at se alle (historiske) transaktioner relateret til kunden og info/noter relateret hertil.

5.1.16 Mulighed for let at sortere og filtrere listen(CRM)

Krav d:
Mulighed for let at sortere og filtrere listen(-erne) over transaktioner (tid, transaktionstype osv.).
Alternativ Id : 424
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Mulighed for let at identificere alle enkelte (historiske) transaktioner.

5.1.17 Bruger og registrering af kundekorrespond.(CRM)

Krav f:



                                                                                                         1
                                                                                             15.12.2005


Hvis relevant info vedr. kundekorrespondance ikke registreres automatisk i systemet, skal bruger oplyses om, at det er
nødvendigt at registrere. Samtidig skal der være mulighed for at registrere kundekorrespondance (forespørgsler).
Alternativ Id : 426
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Kundekorrespondance (herunder telefonresumé) skal kunne registreres let manuelt, i de tilfælde det ikke registreres automatisk.

5.1.18 Seneste 3 transaktioner på 360 graders billedet(CRM)

Krav g:
På forsiden af 360-graders billedet skal min. de seneste 3 transaktioner fremgå med relevant info
relateret til transaktionen, jf. ovenfor. Resten af listen kan evt. ligge i niveauet under.
Alternativ Id : 427
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Bruger skal altid være opdateret med seneste henvendelse til/fra kunden.

5.1.19 X - Registrering af kundens ønsker(CRM)

Krav b:
Registrering af, om kunden ønsker at modtage informationsbreve mm. fra ATP.
Alternativ Id : 431
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1    Ansvarlig : CRM

Accept Kriterie :
Sikre at ATP kun sender standardinformation til de personer, som ønsker det; samtidig minimeres antallet af udsendelser.

5.1.20 Samtaletid for aktive kundesamtaler(CRM)

Krav a:
Samtaletid for aktive kundesamtaler på forsiden af 360-graders billedet. Visningen skal kunne slås
til/fra både af brugeren og fra centralt hold.
Alternativ Id : 437
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Bruger skal hele tiden vide, hvad samtaletiden er for en igangværende samtale. Vigtigt for at overholde performance tidsmål.

5.1.21 Se overenskomst- oplysninger(CRM)

Krav b:



                                                                                                          1
                                                                               15.12.2005


Mulighed for at se overenskomstoplysninger (overenskomstkode, bidragsprocent - overeneskomstrelationer) på
forsidebilledet af 360-grader.
Alternativ Id : 440
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Disse informationer skal være tilgængelige for virksomhedskunder

5.1.22 Se renteoplysninger på 360 grader(CRM)

Krav c:
Renteoplysninger på forsidebilledet af 360-grader.
Alternativ Id : 441
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Disse informationer skal være tilgængelige for virksomhedskunder

5.1.23 X - Automatisk information til kunderådgiver/slutkunde(CRM)

Krav a:
Hvis vigtige/nødvendige oplysninger ikke er registreret i systemet, skal systemet automatisk informere
bruger om at huske at spørge kunden, så opdatering af denne info kan foretages.
Alternativ Id : 448
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Systemet skal hjælpe bruger og sikre bedst mulig kundeservice.

5.1.24 Ændring af info på 360 grader billede(CRM)

Krav a:
Mulighed for at tilføje og ændre (grupper af) informationer i 360-graders billedet i forbindelse med fx
kampagner. Fx i perioden hvor der udsendes pensionsoversigter, skal der på forsiden være som de
informationer, som er relevante i den forbindelse (dvs. de oplysninger som folk typisk spørger til i den
periode).
Alternativ Id : 450
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 04
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Skærmbilledet skal kunne tilpasses løbende kampagner mm.




                                                                                           1
                                                                                              15.12.2005



5.2 Marketing(CRM)



5.2.1     X - Analyse af persondata(CRM)

Krav a:
Mulighed for at inddrage persondata (køn, alder, bopæl, personlig indkomst, husstandsstørrelse, husstandsindkomst,
civilstand, uddannelse mv.) i analyse mhp. identifikation af forklarende variable, segmentering og målgruppeudvælgelse
Alternativ Id : 451
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Kundeindsigt en nødvendig betingelse for individualiseret kommunikation.

Individualiseret kommunikation muliggør at kommunikationen har øget relevans iht. kundens situation, ønsker og behov,
og sikrer derved en værdiskabende kommunikation.

Juridisk grundlag for analyse og kommunikativ anvendelse af kundedata sikres gennem opsamling af samtykkes.

5.2.2     Analyse af stamdata(CRM)

Krav b:
Mulighed for at inddrage stamdata [saldi, , kundestatus (opsparer/pensionist o.a. sondringer), ordningstilhørsforhold mv.] i analysen
mhp. identifikation af forklarende variable, segmentering og målgruppeudvælgelse
Alternativ Id : 452
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt       Prioritet : 1      Ansvarlig : CRM

Accept Kriterie :
Kundeindsigt en nødvendig betingelse for individualiseret kommunikation.

Individualiseret kommunikation muliggør at kommunikationen har øget relevans iht. kundens situation, ønsker og behov,
og sikrer derved en værdiskabende kommunikation.

Juridisk grundlag for analyse og kommunikativ anvendelse af kundedata sikres gennem opsamling af samtykkes.

5.2.3     X - Analyse af holdningsdata(CRM)

Krav c:
Spørgeskema modul, som muliggør opsamling af kendskabs- og holdningsdata, og som kan
integreres med websites
Alternativ Id : 453
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :




                                                                                                            1
                                                                                  15.12.2005


Kundeindsigt en nødvendig betingelse for individualiseret kommunikation.

Individualiseret kommunikation muliggør at kommunikationen har øget relevans iht. kundens situation, ønsker og behov,
og sikrer derved en værdiskabende kommunikation.

Juridisk grundlag for analyse og kommunikativ anvendelse af kundedata sikres gennem opsamling af samtykkes.

5.2.4     X - Analyse af kontaktdata(CRM)

Krav e:
Mulighed for at knytte kontaktdata (navn, bopælsadresse, e-mail adresse, telefon-numre mv.) til
analysen mhp. efterfølgende individualiseret kommunikation pba. analyseresultater
Alternativ Id : 455
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Kundeindsigt en nødvendig betingelse for individualiseret kommunikation.

Individualiseret kommunikation muliggør at kommunikationen har øget relevans iht. kundens situation, ønsker og behov,
og sikrer derved en værdiskabende kommunikation.

Juridisk grundlag for analyse og kommunikativ anvendelse af kundedata sikres gennem opsamling af samtykkes.

5.2.5     X - Analyse af IT-understøttelse(CRM)

Krav f:
Mulighed for at sammenholde holdningsdata, adfærdsdata og persondata (stamdata og kontaktdata) i et analysemiljø.
Alternativ Id : 456
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Kundeindsigt en nødvendig betingelse for individualiseret kommunikation.

Individualiseret kommunikation muliggør at kommunikationen har øget relevans iht. kundens situation, ønsker og behov,
og sikrer derved en værdiskabende kommunikation.

Juridisk grundlag for analyse og kommunikativ anvendelse af kundedata sikres gennem opsamling af samtykkes.

5.2.6     Visning af samtykke i 360-graders billede(CRM)

Krav b:
Visning af samtykke i 360 graders billedet, dels så kunderådgiveren ved hvad kunden har samtykke til, dels så
kunderådgiveren kan agere ud fra samtykket - eksempelvis anbefale en udvidelse af samtykket, eller ved at udnytte
muligheden for kuvertfyld i forbindelse med en allerede planlagt udsendelse (postal eller e-mail).
Alternativ Id : 457
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM




                                                                                              1
                                                                                   15.12.2005




Accept Kriterie :
Opsamling af samtykkes udgør et nødvendigt juridisk og mentalt grundlag for individualiseret kundedialog

5.2.7     Udtræk ordningsspecifikkke data(CRM)

Krav a:
Mulighed for at trække ordningsspecifikke data i segmenteringen:
Køn, alder, saldi, ordning, kunde-status (opsparer, pensionist) etc.
Alternativ Id : 458
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Muliggør differentieret kommunikation

5.2.8     X - Segmentering på relevante data(CRM)

Krav b:
Mulighed for segmentering på relevante data i forbindelse med kampagneplanlægning, herunder målgruppeudvælgelse,
respons, profilanalyser mv. Segmenteringskriterier kan delvist udledes af kravene anført under Kundeindsigt.
Alternativ Id : 459
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Muliggør differentieret kommunikation

5.2.9     X - Segmentering på kampagnedata(CRM)

Krav c:
Mulighed for at segmentere på kampagnehistorik (hvem har tidligere indgået i hvilke kampagner) og responsdata (hvem
responderede, hvordan responderede de og hvad resulterede responsen i).
Alternativ Id : 460
Kravtype : Funktionelt
Kravstiller : Datawarehouse den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Muliggør differentieret kommunikation

5.2.10 X - Integration af kampagnemodul(CRM)

Kampagnestyringsmodul skal integreres med 360 graders billede med bl.a. pop-up leads på in- og outbound kald.

Alternativ Id : 461
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 2  Ansvarlig : CRM




                                                                                              1
                                                                                              15.12.2005




Accept Kriterie :
Vidensdeling, herunder information til KS omkring planlagte kampagner for at sikre intern forankring og korrekt håndtering, eksempelvis
registrering af kundehenvendelser grundet kampagne og information fra Marketing til KS omkring planlagte udsendelser (f.eks. ”i uge
XX bliver saminfo sendt til alle i Nordjylland”).

Mulighed for systematiseret opsamling jf. feedback fra KS - eksempelvis spørgeskema i 360 graders systemet, udnyttelse af FAQ lister,
input til indholdsmæssige justeringer i skriftlige materialer (CMS) mv.

5.2.11 FAQ-lister(CRM)

Krav a:
Kundehenvendelse (ordning, spørgsmål-kategori), persondata, stamdata, kontaktdata, samtykke.
Alternativ Id : 462
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Mulighed for at trække kategoriserede, kvantificerede og dynamiske FAQ lister kan føde Marketing med idéer til nye
kampagner og indholdsmæssige justeringer i skriftlige materialer, som kan være proaktive og derved ressource-
besparende i relation til Kundeservice. Kvantificerede FAQ lister kan desuden indgå i kampagne-evalueringer (antal
henvendelser før og efter kampagnen).

5.2.12 X - Effektmåling(CRM)

Krav a:
Præstationsindikatorer (nøgletal) jf. kampagnens succeskriterier.

Eksempel: En kampagne der i et interaktivt forløb hvor ATP på baggrund af en hændelse (f.eks. at en
besøgende på Folkebørsen laver en risikoprofil) kommunikerer et budskab, der har til formål at
aktivere den besøgende til at udføre en ny hændelse (f.eks. oprettelse af en testkonto). I dette
eksempel vil konverteringsraten være en præstationsindikator - med underliggende nøgletal - for
kampagnen, som kan præsenteres i tabelform og grafisk.
Alternativ Id : 463
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Læring

5.2.13 X - Registrering af kampagnerespons(CRM)

Krav a:
Mulighed for at registrere respons i alle kontaktpunkter (online og offline) for en given kampagne.

Det skal være automatisk registrering ved f.eks. benyttede kuponer (ICR), benyttede selvbetjening (web + telefoni - tast selv service på
kampagnenr. eller registrering ved outbound) mv. Der skal være workflow på kampagner. Resultat registeres i /påvirker workflow.
Alternativ Id : 464
Kravtype : Funktionelt




                                                                                                           1
                                                                                      15.12.2005


Kravstiller : CRM den : 2005 10 05
Status : Nyt     Prioritet : 1   Ansvarlig : CRM

Accept Kriterie :
Responsregistrering er en nødvendig betingelse for gennemførelse og evaluering af marketingkampagner i et
systemmæssigt CRM miljø.

5.2.14 X - Registrering af kunderettede aktviteter mv.(CRM)

Krav b:
Mulighed for jf. respons at registrere efterfølgende aktiviteter både internt, outbound og inbound.

Alternativ Id : 465
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Responsregistrering er en nødvendig betingelse for gennemførelse og evaluering af marketingkampagner i et
systemmæssigt CRM miljø.

5.2.15 X - Rapportering af kampagnerespons(CRM)

Krav c:
Mulighed for at trække statistikker for respons, efterfølgende aktiviteter, og eventuelle kunderesultater (eksempelvis øget
opsparing) som en kampagne har resulteret i.
Alternativ Id : 466
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Responsregistrering er en nødvendig betingelse for gennemførelse og evaluering af marketingkampagner i et
systemmæssigt CRM miljø.

5.2.16 X - Identifikation af målgrupper(CRM)

Krav a:
Identifikation af målgruppe(r), eksempelvis pba. analytisk CRM, FAQ lister eller internt/eksternt skabt informationsbehov.
Alternativ Id : 467
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Målgruppeudvælgelse, herunder kampagneregistrering, er en nødvendig betingelse for at planlægge og gennemføre
marketingkampagner i et systemmæssigt CRM miljø.

5.2.17 X - Udvælgelse af målgrupper(CRM)

Krav b:




                                                                                                      1
                                                                                             15.12.2005


Udvælgelse af målgruppe, herunder fravalg af emner jf. segmenteringskriterier og/eller kampagnehistorik (eksempelvis
emner, som tidligere har modtaget materialet eller emner som allerede har svaret på kampagnen).
Alternativ Id : 468
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Målgruppeudvælgelse, herunder kampagneregistrering, er en nødvendig betingelse for at planlægge og gennemføre
marketingkampagner i et systemmæssigt CRM miljø.

5.2.18 X - Kampagneregistrering for målgruppe(CRM)

Krav c:
Masseregistrering på individ niveau af Personer/Virksomheder, der indgår i en given kampagne, herunder registrering af
kampagnenavn, kampagneaktivitet, dato, og referencer til kampagnematerialer.
Alternativ Id : 469
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Målgruppeudvælgelse, herunder kampagneregistrering, er en nødvendig betingelse for at planlægge og gennemføre
marketingkampagner i et systemmæssigt CRM miljø.

5.2.19 X - Regelstyring for kunderettet kommunikation(CRM)

Krav b:
Implementering af regler for hændelsesbaseret kommunikation.

Regler for al kommunikation og sagsbehandling skal indgå i denne regelmotor (del af informationsmodel) f.eks. differentierede regler
som følge af størrelse, VIP-markering, tiltaleform, koncern- og slutkundevalg, adfærd, profil mv.
Alternativ Id : 471
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Accepteret        Prioritet : 2       Ansvarlig : CRM

Accept Kriterie :
Hændelsesbaseret kommunikation sikrer maksimal relevans i forhold til kunden, og sikrer derved at ATP's kommunikation
opleves som værdiskabende.

5.2.20 X - CRM på webben(CRM)

CRM funktionaliteten skal også kunne bruges på webben - eksempelvis således at
   kundens adfærd registreres
   de sidste applikationer, kunden anvendte præsenteres straks ved næste log-in fra samme kunde
   kampagner kan gennemføres via pop-up eller lignende.
Alternativ Id : 485
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 20
Status : Nyt       Prioritet :    Ansvarlig : CRM




                                                                                                          1
                                                                                   15.12.2005



5.3 Analytisk CRM



5.3.1     Informartionsbærende data i analysemart(CRM)

Krav b:
Alle informationsbærende data skal samles og stilles til rådighed i en analysemart:
Der arbejdes med kæmpe datamængder i CRM regi, hvorfor det er hensigtsmæssigt at opsamle og placere dataene et
sted.

Analysemart er en del af datavarehus.
Alternativ Id : 474
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1    Ansvarlig : CRM

Accept Kriterie :
Lave tværgående analyser og dermed kunne drage fordele ved at tage det bedste fra den enkelte ordning og anvende det
på de øvrige. Yderligere er det nødvendigt at kende historikken omkring en Person/Virksomhed/Koncernkunde på min. 2
år

5.3.2     Opsamling af kundens kanalvalg(CRM

Krav d:
Identificere kanalvalg:
Opsamling af kundens kanalvalg (web, telefoni,…)
Alternativ Id : 475
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Kendskab til kundernes foretrukne kanalvalg medfører, at vi kan tilrette vores henvendelser mod kunden

5.3.3     Kategorisere kundehenvendelser(CRM)

Krav f:
Kategorisere kundehenvendelser (klage, sagstype, forespørgsel,…) Dog max. 10 kategorier.

Giver information om kundehenvendelsestypen og ATP kan pba. informationen blive bedre til at undgå unødig kontakt fra
kunderne. 360 graderbilledet må ikke forlades uden at sagsbehandleren har taget stilling til henvendelsen.
Alternativ Id : 477
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
Informationsværdien er lig 0, hvis ikke ATP kvantificere henvendelserne fra kunderne




                                                                                              1
                                                                                     15.12.2005



5.3.4     X - Resultater fra spørgeskemaerne ind i en analysemart(CRM)

Krav g:
Resultaterne fra spørgeskemaerne skal stilles til rådighed i en analysemart, så det er muligt at analysere resultaterne
efterfølgende.

Opfølgning og ekstra kendskab til kunderne ønsker og behov.
Alternativ Id : 478
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 2  Ansvarlig : CRM




5.3.5     X - Resultat fra analytisk CRM ind i 360 graders billede(CRM)

Krav a:
Resultater fra Analytisk CRM skal kunne håndteres/implementeres i NAFS/360 graderbilledet som l agdelt information med
mulighed for at kunne gå i dybden.

Salgssignaler og segmenter mm. skal kunne præsenteres og anvendes proaktivt af sagsbehandleren.

Alternativ Id : 479
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 1  Ansvarlig : CRM

Accept Kriterie :
For at anvende CRM operationelt er det nødvendigt at kunne præsentere resultaterne overfor sagsbehandleren .

5.3.6     X - Håndtering af spørgeskemaer(CRM)

Krav b:
Håndtering af spørgeskemaer.
Via alle kanaler skal det være muligt at afvikle spørgeskemaer, hvor svarene samles op til analyse. Mulighed for
advisering af sagsbehandleren om at et spørgeskema skal/kan afvikles(både push og pull), når der alligevel er kontakt
med kunden telefonisk.
Alternativ Id : 480
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Det er mere omkostningsbesparende at afvikle et spørgeskema, når det er kunden der ringer .

5.3.7     X - Vedligeholdelse af spørgeskemaer(CRM)

Krav c:
Faciliteter til at opsætte og vedligeholde spørgeskemaer.

Sagsbehandleren skal kunne gennemføre spørgeskemaer f.eks. i forbindelse med markedsundersøgelser.
Alternativ Id : 481




                                                                                                 1
                                                                                       15.12.2005


Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt     Prioritet : 2   Ansvarlig : CRM

Accept Kriterie :
Feedback fra kunderne mere viden der kan bruges målrettet den enkelte kunde eller kundegruppe.

5.3.8    X - Driften af spørgeskemaer(CRM)

Krav c1:
Driften af spørgeskemaer.

Det skal være muligt for forretningen at lave og implementere spørgeskemaer selv. Ansvaret for spørgeskemaer og
rettelser skal ligge i forretningen.
Alternativ Id : 482
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt      Prioritet : 2  Ansvarlig : CRM

Accept Kriterie :
Rettelser skal være mulig for forretningen at foretage, så de kan slå igennem indenfor 30 min. ved evt. fejl .


5.3.9    Datafangst ved selvbetjeningsfunktionalitet(Portal)

Kunden kan selv rette sine visse af sine personlige data.

Konkrete krav specificeres i use cases.

Eksempler:
   email
   telefonnummer
   permission marketing
     samtykke
     reg.nr./kto.nr.
     trækprocent
     valgbillede for slutkunde.
Alternativ Id : 484
Kravtype : Funktionelt
Kravstiller : CRM den : 2005 10 05
Status : Nyt       Prioritet : 3 Ansvarlig : CRM

Accept Kriterie :
Kunden får et medansvar for at opdatere sine oplysninger




                                                                                                   1
                                                                                  15.12.2005




6   G CALL CENTER

Call Center


       Fuldt programmerbart(CC)                                Beredskab af voices(CC)


       X - Tidstro ændring(CC)                                 Call back og SMS(CC)


       Intelligent routning af opkald(CC)                      Hændelsestyret organisering(CC)


       X - Mulighed for ændring i opsætning(CC)                Betjening via flere filtre(CC)


       360 graders billede(CC)                                 Direkte afsendelse af bekræftelse(CC)


       Kundeselvbetjening(CC)                                  Servicetelefon med talegenkendelse(CC)


       X - Outbound aktiviteter(CC)                            Alarm funktion for call back(CC)


       70èr numre(CC)                                          Statistikker(CC)


       Ad hoc meddelelser(CC)                                  Planlægning af produktion(CC)


       X - Co-brow sing(CC)                                    X - Lyt med agent(CC)


       Warning ved overskridelse af                            X - Optagelse af tlf.samtaler(CC)
       servicemål(CC)

       Kampagne-telefonnumre(CC)



                                             Figure 6 G CALL CENTER




                                                                                            1
                                                                                           15.12.2005



6.1 Call Center



6.1.1      Fuldt programmerbart(CC)

Voice response systemet skal være fuldt programmerbart med hensyn til menuer og integration med
medlems-databaserne.

Kravbesvarelse:
Produktionsafdelingen har det tekniske ansvar for organiseringen af denne vedligeholdelses problematik.

Det indebærer at der til et nyt telefonnr. eller ændringer til et bestående udvikles en strategi, hvilket er et script lignende
program, som kræver kompetence i brugen af dette sprog. Denne kompetence besidder kun TDC's specialister og det er
kontraktlig aftalt gennem en service kontrakt at al vedligeholdelse udføres af TDC. Hvis denne organisering skal ændres
kræver det altså en ny service aftale med TDC, foruden at kompetencen skal opbygges i atp regi.


Alternativ Id : 500
Kravtype : Non-funktionelt
Kravstiller : Krav-PIXI den : 2005 08 23
Status : Nyt       Prioritet :     Ansvarlig : Call Center




6.1.2      X - Tidstro ændring(CC)

ATP ønsker selv at kunne effektuere ændringer i call routing, IVR manuskripter, medarbejderskills og
andet.

Systemerne skal derfor i høj grad kunne serviceres af egne (tilstrækkeligt trænede) medarbejdere.
Disse ændringer skal alle som udgangspunkt kunne foretages real-time med øjeblikkelig virkning og
uden at re-boote systemerne.
Alternativ Id : 501
Kravtype : Non-funktionelt
Kravstiller : Krav-PIXI den : 2005 08 23
Status : Nyt       Prioritet :     Ansvarlig : Call Center




6.1.3      Intelligent routning af opkald(CC)

Call Center teknikken skal understøtte, at opkaldet intelligent ledes hen til den rette sagsbehandler,
idet der bl.a. skal tages hensyn til:
       Igangværende sager for den pågældende kunde og aftale.
       Organiseringen af sagsbehandlere i grupper efter kompetencer, ordninger, bestande, kunder og aftaler.
       Tidspunkt på døgnet.
       Det skal være mulig at PensionService dynamisk kan indkobles som overløb for PS Kunderne, fx. ved kapacitetsproblemer.
        Endvidere skal det være muligt at tilkoble et eksternt Call Center som back-up.




                                                                                                       1
                                                                                          15.12.2005



Routningen skal være parameterstyret og vi skal selv kunne ændre parametrene fx ved integration mod HR-systemet.

Kundebetjenere som kan tilmeldes kæden og ikke er det, skal via sms, e-mail, messenger gøres
opmærksomme på, at de skal tilmelde sig en af 'deres' kæder indenfor et beregnet tidsrum, ved
forventede problemer med overholdelse af SLA (Service Level Agreement). Derefter skal den
enkelte kundebetjener kunne tilmelde sig den pågældende kæde med problemet.


Alternativ Id : 502
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 08 23
Status : Nyt       Prioritet :     Ansvarlig : Call Center




6.1.4      X - Mulighed for ændring i opsætning(CC)

Udvalgte medarbejdere (fx førstelinjelederen eller specialister) skal have mulighed for selv at:
       ændre parametre som styrer routingen af indkomne telefoner
       ændre talemeddelelser og talegenkendelse, som ligger i telefonsystemet
       rette og styre voices
       effektuere ændringer i IVR manuskripter
       opbygge menustrukturer til f.eks. selvbetjening.

Det skal være mulig at ændre indenfor 15 minutter.
Alternativ Id : 503
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 21
Status : Nyt      Prioritet :      Ansvarlig : Call Center




6.1.5      360 graders billede(CC)

360-graders billedet ”popper op” automatisk på brugers skærm, når en kunde ringer, herunder:
1: Relevant ordningsinfo på baggrund af det kaldte kædenummer.
2: Relevant person/SE og ordningsinfo, når kunden har indtastet sit CPR/SE-nummer.

360-graders billedet skal kunne 'sendes med' til den nye bruger ved omstilling af kaldet.


Alternativ Id : 504
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 20
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.6      Kundeselvbetjening(CC)

Kunden skal have mulighed for at selvbetjene sig via telefonløsning uden involvering af rådgiver.



                                                                                                     1
                                                                                   15.12.2005




Tryk selv-service skal omfatte en lang række selvbetjeningsmuligheder (fx afgivelse af
samlevererklæringer.) evt. med igangsætning af workflow. Der skal også kunne gives
svar/simuleringer tilbage (samme datakonmponent/interface som ved web-selvbetjening).

Tryk selv-service kan være på generelt nr. til dette eller særlige kampagnenr. f.eks. kun anmodning
om udbetaling af alderspension på baggrund af DM.

Skal også omfatte automatisk talegenkendelse (besvarelse af spørgsmål).

Alternativ Id : 505
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 21
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.7     X - Outbound aktiviteter(CC)

Systemet skal gøre det muligt at generere forskellige typer
af rapporter når vi ringer ud på en bestemt type opgaver.
Eksempel på opgavetyper:
       Erindringsopkald
       Opfølgning på velkomstpakken til medlemmer
       Opfølgning på velkomstpakken til virksomheder
       Servicering af førtidspensionister med henblik på SUPP
       Serviceopkald til lokalafdelinger
       Bookning af kundechefmøder
       Servicering af virksomhed

Formålet er:
     at følge hvor langt vi er kommet med forskellige aktiviteter
     at se hvad har vi brugt af ressourcer
     at se hvor mange har vi kontaktet / fået opkald fra




Alternativ Id : 506
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 21
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.8     70èr numre(CC)

Vi ønsker mulighed for at benytte et væsentligt (ubegrænset) antal 70-er numre.

Alternativ Id : 507
Kravtype : Funktionelt




                                                                                           1
                                                                                   15.12.2005


Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 21
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.9      Ad hoc meddelelser(CC)

Call centret skal kunne håndtere "ad hoc" meddelelser - også de systemer med
selvbetjeningsfunktioner.
Håndtering af ad hoc meddelelser skal kunne fungere uanset hvilket system Call Center anvender. Ad
hoc meddelelser skal kunne lægges på øjeblikkeligt når behov opstår.

Alternativ Id : 508
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 03
Status : Nyt       Prioritet :    Ansvarlig : Call Center




6.1.10 X - Co-browsing(CC)

Der skal være mulighed for "co browsing" kunne overtage kundens skærm ifb. med et evt. problem
på nettet.

Kravbesvarelse:
Kravet håndteres af Portal
Alternativ Id : 509
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 03
Status : Nyt       Prioritet :    Ansvarlig : Call Center




6.1.11 Warning ved overskridelse af servicemål(CC)

Call Centret skal give en 'warning' når et servicemål forventes overskredet (gennemsnitlig ventetid,
maksimal ventetid, tabt opkald). Som følge af forudsigelsen skal det estimeres i samme sekund:

       hvor mange ekstra ressourcer der skal tilkobles
       hvilken kæde
       hvem (af de tilmeldte og de ikke tilmeldte som kan tilmeldes)
       hvornår

Warning skal kunne gives på forskellige medier og også til eksterne.
Alternativ Id : 510
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 03
Status : Nyt       Prioritet :     Ansvarlig : Call Center




                                                                                           1
                                                                                   15.12.2005



6.1.12 Kampagne-telefonnumre(CC)

Vi skal have mulighed for at benytte et væsentligt (ubegrænset) antal kampagne-telefonnumre , så vi
kan udnytte eksisterende i kampagne-telefonnummer-funktionalitet endnu mere optimalt.

Kampagnenr. skal kunne etableres af superbruger.
Kampagnenr. kan indstilles til routning til særlige gruppe eller til tryk selv-service
Alternativ Id : 511
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 21
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.13 Beredskab af voices(CC)

Der skal være mulighed for en midlertidig og permanente menutyper, der kan lagres i flere versioner
til genbrug. De midlertidige menutyper kan benyttes i forbindelse med store udsendelser, hvor man vil
give mulighed for menupunkter, som ikke tilbydes normalt eksempelvis midlertidige
kundeundersøgelser, selvbetjening o.a. Man kunne også forestille sig sæsonafhængige menutyper.

Alternativ Id : 512
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 21
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.14 Call back og SMS(CC)

Systemet skal have call back-funktion og SMS-funktion.
Opkalderen skal kunne vælge Call Back tidspunkt, samt emne for opringning.
Alternativ Id : 513
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 21
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.15 Hændelsestyret organisering(CC)

Vi skal have mulighed for hændelsesstyret organisering i stedet ordningsstyret .
Betyder bl.a., at telefonen dirigeres til eksempelvis: Feriekonto, PensionDenmark, Workflow.
Alternativ Id : 514
Kravtype : Non-funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 20
Status : Nyt      Prioritet :   Ansvarlig : Call Center




                                                                                           1
                                                                                   15.12.2005




6.1.16 Betjening via flere filtre(CC)

Betjeningen skal kunne foregå som en tragt med flere filtre (menustruktur).
Man skal kunne rute tryk-selv telefonopkald eller talegenkendelse til den ønskede service/ydelse
f.eks. dødsudbetaling, feriepengeudbetaling, pensionering.

Ruterne skal være defineret på forhånd. F.eks. rute fra særligt kampagnenr. og fra web-
selvbetjeningsværktøj til samme datakompenent (data ind: indtastninger og ud: svar/simuleringer)
vedrørende udbetaling ved alderspensionering. Begge kanaler igangsætter workflow (samme
hovedproces).

Alternativ Id : 515
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 20
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.17 Direkte afsendelse af bekræftelse(CC)

Der skal være mulighed for direkte afsendelse af bekræftelse.

Kravbesvarelse:
Der opsamles data til brug for et givet forretningssystem og domænet "Dokumenthåndtering" sørger
for afsendelsen, hvorfor skal Call Center (bland flere andre) skal integreres med
Dokumenthåndtering.
Alternativ Id : 516
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 20
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.18 Servicetelefon med talegenkendelse(CC)

Der skal være en servicetelefon med talegenkendelse som f.eks. Feriekonto

Alternativ Id : 517
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 20
Status : Nyt      Prioritet :   Ansvarlig : Call Center




6.1.19 Alarm funktion for call back(CC)




                                                                                           1
                                                                         15.12.2005



Alarm funktion for call back, som popper op hos den ansvarlige med angivelse af tidspunkt for
kontakt, telefonnr. mv.

Alternativ Id : 518
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 03
Status : Nyt       Prioritet :    Ansvarlig : Call Center




6.1.20 Statistikker(CC)

Der skal være statistikker, som lederne minut for minut kan benytte til at vurdere forløbet i Call
Centret, for at kunne lære af de historiske sammenhænge.

Kravbesvarelse:
Der er tale om en ny udviklingsopgave.
Skal konkretisers yderligere af lederne.

Alternativ Id : 519
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 03
Status : Nyt       Prioritet :    Ansvarlig : Call Center




6.1.21 Planlægning af produktion(CC)

Mulighed for planlægning af produktionen, f.eks. hvad skal der til for at et given produkt realiserer et
givent servicemål, og hvor mange "medarbejdere/agenter" skulle der have været for at realisere et
givent servicemål.
Det derjer sig om at kunne i real-tid (online)allokere flere ressourcer til Call Center, hvis eksempelvis
ventiden overskrides. Der et behov for et slag overvågningsværktøj.


Kravbesvarelse:
Man kan overveje om det er i Call Center systemet at planlægningen skal lægges, da
ressourceudnyttelsen skal planlægges i sammenhæng med sagsbehandlingen.

Alternativ Id : 520
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 03
Status : Nyt       Prioritet :    Ansvarlig : Call Center




6.1.22 X - Lyt med agent(CC)




                                                                                   1
                                                                       15.12.2005



Lyt med agent der aktiverer dialog bokse på skærmen, så en medarbejder kan håndtere flere
produkter.
Lyd med agenten skal bruges i forbindelse med kunderådgivning. Tanken er, at en intelligent
agenten skal kunne fange nøgleord fx. "udbetaling", "udsættelse af pensionsalder", "feriepenge" etc.
og vejlede sagsbehandleren i effektuering af opgaver relaterede til nøgleordene.

Alternativ Id : 521
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 03
Status : Nyt       Prioritet :    Ansvarlig : Call Center




6.1.23 X - Optagelse af tlf.samtaler(CC)

Det skal være muligt at optage en tlf.samtale og efterfølgende journalisere og evt. genhøre lydfilen.

Alternativ Id : 522
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 20
Status : Nyt       Prioritet :    Ansvarlig : Call Center




                                                                                 1
                                                                                                         15.12.2005




7     H DOKUMENTHÅNDTERING

Definition: Dokument er en informationsbærende enhed - fx brev, tlf.samtale, e-mail, datafil el. lign.


Journalisering (DH)


      Journalisering af dokumenter (DH)                        Metadata (DH)




Visning (DH)

      Preprint visning (DH)                                    Visning af dokument (DH)




Lagring (DH)

      Søgning (DH)                                             Arkivoverblik (DH)




Capture (datamodtagelse) (DH)


      X - Scanning (DH)                                        Kanaler, medier og formater (DH)           Returpost (DH)

      Icr-fortolkning (DH)

      Fuldtekst genkendelse (DH)


Dokumentudvikling (DH)


      Print af dokumenter (DH)                                 Individualiserede breve (DH)               Anvendelse af tekstelementer på tværs (DH)


      X - Udsendelsesperformance (DH)                          Branding (DH)                              Ændringer i breve (DH)


      Genudskrive breve (DH)                                   Underskriftsfil (DH)                       Understøttet brevindhold (DH)


      Samkuvertering (DH)                                      Sprog (DH)                                 Fritekst (DH)


      Kanalvalg (DH)                                           Datering af breve (DH)                     Hentning af fritekster (DH)

      Bundtning ifm masseudsendelser(DH)




                                                                   Figure 7 H DOKUMENTHÅNDTERING




                                                                                                                          1
                                                                       15.12.2005



7.1 Journalisering (DH)



7.1.1     Journalisering af dokumenter (DH)

Alle modtagne og afsendte dokumenter skal journaliseres efter en journalplan.
Journalisering består i tildeling af dokumenttype og andre metadata til dokumentet. Disse data skal
bruges til at beskrive dokumentets videre forløb (i fht. workflow) og til registrering.

Journalisering skal kunne foretages maskinelt og manuelt.

Det skal desuden være muligt at journalisere tilknyttede dokumenter.
Alternativ Id : 600
Kravtype : Funktionelt
Status : Nyt      Prioritet :   Ansvarlig : Dokumenthåndtering




7.1.2     Metadata (DH)

Metadata skal tilføjes alle dokumenter. Disse tilføjes bl.a. vha. dokumenttyper, som er definerede i
journalplanen.

Metadata skal kunne danne grundlag for behandling af dokumenter.

Metadata skal kunne bruges til ledelsesrapportering og skal integreres til datavarehus.


Alternativ Id : 601
Kravtype : Funktionelt
Status : Nyt      Prioritet :   Ansvarlig : Dokumenthåndtering




7.2 Visning (DH)



7.2.1     Preprint visning (DH)

Man skal kunne se brevet som pre-print, når man skriver individuel tekst i fritekstfelter og når man
ændrer i breves indhold.

Alternativ Id : 602
Kravtype : Funktionelt




                                                                                  1
                                                                      15.12.2005


Kravstiller : Dokumenthåndtering den : 2005 08 31
Status : Nyt      Prioritet :    Ansvarlig : Dokumenthåndtering




7.2.2     Visning af dokument (DH)

Alle elektroniske og scannede dokumenter skal kunne vises i oprindelig form.

Det må tage max 2 sekunder at genskabe et dokument
Alternativ Id : 603
Kravtype : Funktionelt
Status : Nyt      Prioritet :   Ansvarlig : Dokumenthåndtering




7.3 Lagring (DH)



7.3.1     Søgning (DH)

Det skal være muligt at fremsøge dokumenter og sager via metadata. I de tilfælde, hvor breve er
gemt som tekst-dokumenter og ikke billeder, skal det være muligt at søge i fuldtekst dokumentet.

Alternativ Id : 605
Kravtype : Funktionelt
Status : Nyt      Prioritet :   Ansvarlig : Dokumenthåndtering




7.3.2     Arkivoverblik (DH)

Dokumenter skal lagres i en emnestruktur, som giver hurtigt overblik over arkivet.

Alternativ Id : 606
Kravtype : Funktionelt
Kravstiller : Dokumenthåndtering den : 2005 08 31
Status : Nyt      Prioritet :    Ansvarlig : Dokumenthåndtering




7.4 Capture (datamodtagelse) (DH)




                                                                                1
                                                                       15.12.2005



7.4.1    X - Scanning (DH)

Alle dokumenter, der modtages, skal kunne scannes og arkiveres elektronisk i et visningssikret
format.

Alternativ Id : 607
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 10 03
Status : Nyt       Prioritet :     Ansvarlig : Dokumenthåndtering




7.4.2    Icr-fortolkning (DH)

Så vidt muligt skal modtagne dokumenter icr-fortolkes i scanningen.

I de tilfælde, hvor data ikke kan genkendes i en icr-fortolkning, skal dokumentet efter scanning
journaliseres manuelt.

Alternativ Id : 608
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 10 04
Status : Nyt       Prioritet :     Ansvarlig : Dokumenthåndtering




7.4.3    Fuldtekst genkendelse (DH)

Systemet skal kunne håndtere dokumenter, som indekseres vha. fuldtekstfortolkning

Til at understøtte fremtidig fuldtekstskanning, skal systemet kunne understøtte modtagelse af
dokumenter (ikke billeder af dokumenter) med søgbar tekst og automatisk indeksering af dokumenter
uden indekseringskode (genkendelse af ord opstillet efter parametre)

Alternativ Id : 609
Kravtype : Funktionelt
Kravstiller : Dokumenthåndtering den : 2005 09 05
Status : Nyt      Prioritet :    Ansvarlig : Dokumenthåndtering




7.4.4    Kanaler, medier og formater (DH)

I modtagelsen skal det være muligt at håndtere struktureret og ustruktureret tekst.

Noget data vil blive pre-indekseret i modtagelsen(telefon, hvor kunden påforhånd har tastet, hvilket
område vedkommende henvender sig omkring, eller emne-struktureret e-mail). Disse data vil skulle




                                                                                 1
                                                                                                 15.12.2005



journaliseres til ende som ustruktureret tekst, og det skal være muligt at rette indekseringen, hvis
kunden har tastet forkert.


KANALER:
I modtagelsen af dokumenter til følgende kanaler være tilgængelige:
     Post Danmark
     Fax
     E-mail
     Portal
     Telefon
     EDI*

MEDIER:
Følgende medier understøttes:
     Papir-medie max A4 (herunder fax og billede)
     Elektroniske medier

FORMATER:
For fysisk post kan følgende formater understøttes:
      Maskin og håndskrevne breve
      Blanketter som er udviklet af ATP
      Fax
      Billeder på papir

Elektroniske formater kan bestå af struktureret data (i portaler) og ustruktureret data (i emails).
Modtagelse af emails skal understøttes med udgangspunkt i oio-standarden for emails.
Vedhæftede filer i emails kan modtages, men kun et begrænset omfang af formater kan understøttes (her henvises til
http://www.videnskabsministeriet.dk/fsk/publ/2005/God_brug_af_e-post/)

fx:
       pdf
       gængse MS-office formater


Elektroniske formater modtaget på fysiske medier understøttes ikke!


Alle medier og kanaler skal ligestilles i fht. registreringen af modtagne dokumenter.

* Policer ved overførsel af kunde mellem to pensionselskaber (overførsel af SP og LD) vil i de blive sendt via EDI. Denne overførsel
       skal journaliseres, således at det, på lige fod med alle andre dokumenter, vil være muligt at se i kundens 'record' eller historik.

Alternativ Id : 610
Kravtype : Funktionelt
Status : Accepteret         Prioritet :        Ansvarlig : Dokumenthåndtering




7.4.5      Returpost (DH)

Al returpost skal registreres og kunne håndteres maskinelt vha. indekseringskode




                                                                                                               1
                                                                           15.12.2005



Returpost behandles på lige fod med al andet indgået post (dvs. indekseringskode genkendes og
    starter workflow). Vha. en indekseringskode i adresse-ruden, skal returpost kunne genkendes
    uden at behøve at åbne kuverten. Registrering af indekseringskode trigger WF (fx at kunden
    sættes i bero)


Link til serviceoperationer:
JournaliserDokument
Alternativ Id : 611
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 08 30
Status : Nyt       Prioritet :     Ansvarlig : Dokumenthåndtering




7.5 Dokumentudvikling (DH)



7.5.1     Print af dokumenter (DH)

Dokumenter til udsendelse skal kunne printes centralt såvel som decentralt.

Central printning vil være den foretrukne metode, og rettigheder til printning decentralt skal styres for
    hvert enkelt dokument.

Det skal desuden være muligt at printe decentralt uden at journalisere til brug for sagsbehandling eller
     test. Denne type print skal være markeret, fx med vandmærke 'til internt brug', således at den
     ikke kan anvendes til forsendelse.

Print til brug for sagsbehandling skal altid journaliseres (automatisk).


Alternativ Id : 612
Kravtype : Funktionelt
Status : Nyt      Prioritet :      Ansvarlig : Dokumenthåndtering




7.5.2     X - Udsendelsesperformance (DH)

Ad hoc breve, som er bestilt ved skærmen kan forventes hos modtageren dagen efter bestiling, under
forudsætning af at de er bestilt inden kl.16

Alternativ Id : 613
Status : Prioritet :       Ansvarlig :




                                                                                   1
                                                                                          15.12.2005




7.5.3      Genudskrive breve (DH)

Det skal til en hver tid være muligt at (gen)udskrive dokumenter.

Eks:
Kunden ringer ind. Har modtaget et brev, men hunden har spist det, så vedkommende vil gerne have
tilsendt et nyt.

Alternativ Id : 614
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 08 31
Status : Nyt       Prioritet :     Ansvarlig : Dokumenthåndtering




7.5.4      Samkuvertering (DH)

Det skal være muligt at samkuvertere, parameterstyret, på tværs af ordninger.

Det skal være muligt maskinelt at prisfastsætte overfor koncernkunde, når der samkuverteres
Alternativ Id : 615
Kravtype : Funktionelt
Kravstiller : Dokumenthåndtering den : 2005 08 31
Status : Nyt      Prioritet :    Ansvarlig : Dokumenthåndtering




7.5.5      Kanalvalg (DH)

Kanalvalg er styret af kundens præferencer (CRM)

Dokumenthåndteringen skal kunne understøtte følgende udsendelseskanaler:

       Papir
       E-mail
       E-boks (pdf)
       EDI* (se Capture)


Hvis juridiske hensyn kræver det, skal kundens kanal-præference kunne overrules.

* I forbindelse med overførsel af SP og LD skal kundens ønske om overførsel ske via EDI (nuv. proces foregår ved at kunden sender
        anmodning til os, vi taster anmodningen - indtaster cpr - i vores EDI-udbakke og sender den).
Alternativ Id : 616
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 08 31
Status : Nyt       Prioritet :        Ansvarlig : Dokumenthåndtering




                                                                                                       1
                                                                                               15.12.2005




7.5.6      Bundtning ifm masseudsendelser(DH)

Brevene indenfor en given masseudsendelse skal kunne bundtes hensigtsmæssigt i forhold til
volumen af hensyn til prisstruktur og leverandøraftaler. Bundtningen skal kunne parameterstyres.

Alternativ Id : 627
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 20
Status : Nyt       Prioritet :    Ansvarlig : Dokumenthåndtering




7.5.7      Individualiserede breve (DH)

Det skal være muligt at udvikle komplekse og individualiserede breve til enkelte eller store                              grupper af
        modtagere med data fra NAFS.

Eks:
       Ved årsudsendelser skal det være muligt via kontakt til andre systemer at skabe individualiserede breve med bl.a. forsikrings- og
        dækningsoversigt.
       Adresse på modtager bliver maskinelt påført brevet via vores interessentregister.
       Koncernkundens logo og aftalte brand påføres dokumentet, når koncernkunden er kendt.

Disse breve skal både kunne skabes til enhver tid, fx i forlængelse af en kundekontakt, eller i større klumper i forbindelse med
årsudsendelser, eksempelvis ved gruppe-/bestandsændringer.



Alternativ Id : 617
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 09 01
Status : Nyt       Prioritet :     Ansvarlig : Dokumenthåndtering




7.5.8      Branding (DH)

Det skal være muligt at definere et særligt brand til en udsendelse, vha. differencierende fonte, logo
m.m.

Dette skal dog ligge inden for de rammer, der stilles op af designmanualen.

Som minimum skal alle fonte vi idag anvender kunne anvendes fremover.
Alternativ Id : 618
Kravtype : Funktionelt
Status : Nyt      Prioritet :        Ansvarlig : Dokumenthåndtering




                                                                                                            1
                                                                                          15.12.2005



7.5.9    Underskriftsfil (DH)

Det skal være muligt at anvende en underskriftsfil på tværs af breve


I nogle masseudsendelser kan det være påkrævet at have en underskrift fra direktøren. Denne skal
tilføres brevet som et parameter, der kan ændres selvstændigt.

Bemærkninger:
Dette skal ses ud fra ønsket om at have en underskrift på masseforsendelser. En forretningsmæssig beslutning om at kunderådgivere
ikke skriver personligt under på breve, påvirkes ikke af dette krav.
Alternativ Id : 619
Kravtype : Funktionelt
Kravstiller : Dokumenthåndtering den : 2005 08 31
Status : Nyt      Prioritet :        Ansvarlig : Dokumenthåndtering




7.5.10 Sprog (DH)

Breve skal kunne oversættes til flere sprog

Det skal være muligt at vælge et brev på et andet sprog, hvis fx oplysninger om kunden anviser det.

Alternativ Id : 620
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 08 31
Status : Nyt       Prioritet :     Ansvarlig : Dokumenthåndtering




7.5.11 Datering af breve (DH)

Datering af breve skal ske automatisk og skal være styret af den valgte udsendelsesdato.


I tilfældet, hvor en kunderådgiver vælger at tilbageholde breve (printlogistik) eller hvor en
masseudsendelse udsendes over en længere periode (Fremadrettet produktionsplanlægning), skal
datoen være styret af den dag, brevet vælges at blive sendt ud og ikke den dag det genereres.
Alternativ Id : 621
Kravtype : Funktionelt
Kravstiller : Dokumenthåndtering den : 2005 09 05
Status : Nyt      Prioritet :    Ansvarlig : Dokumenthåndtering




7.5.12 Anvendelse af tekstelementer på tværs (DH)




                                                                                                       1
                                                                                              15.12.2005



Tekstelementer skal kunne anvendes på tværs af alle breve og ordninger, således at genbrug af tekst
kan blive så stort som muligt.

Det skal være muligt at få et overblik over tekstelementernes anvendelse. Dette skal bruges til at
overskue konsekvenserne af en rettelse i specifikke tekstelementer.
Alternativ Id : 622
Kravtype : Funktionelt
Status : Nyt      Prioritet :       Ansvarlig : Dokumenthåndtering




7.5.13 Ændringer i breve (DH)

Ændringer skal kunne ses og printes direkte fra skærm.
Ændringer i breve skal kunne fortages efter nedenstående retningslinier. Tidsestimaterne skal forstås som den kalendertid der går fra
en ændring er defineret/specificeret og afleveret til den/de som skal løse opgaven frem til løsningen er klar til idriftsættelse.

Vedligeholdelse (eksisterende print) skal kunne ske nemt internt og eksternt. Det gælder også brevadministrationen via workflow (f.eks.
tilkobling af nye breve).

Simpel ændring - max 1 time
En simpel ændring består i en tekstændring eller en ændringen i formuleringer i ét brev, hvor tekstelementet, som rettes, ikke går igen i
flere breve.

Middelkompliceret ændring - max 1 dag
En middelkompliceret ændring består i tekstændringer eller ændringer i formuleringer i et eller flere breve, hvor de ændrede
tekstelementer går igen i flere breve.

En middelkompliceret ændring vil også kunne bestå i simple ændringer i tekstvariable. Simple variabelændringer kan fx være ændring
af tekstvariabel (men ikke ændring af systemvariabel hentet fra kernen).

Kompliceret ændring - max 2 uger
En kompliceret brevændring vil bestå i rettelser og udvikling af hele brevkomplekser (tekst på tværs af breve), indhentning nye
blanketter, kuverter eller aftaler om ekstern produktion.
En kompliceret ændring vil også være en ændring i layout eller opsætning af breve.

Ændringer af systemvariable vil også være placeret under denne ændringstype.
Alternativ Id : 623
Kravtype : Funktionelt
Status : Nyt      Prioritet :      Ansvarlig : Dokumenthåndtering




7.5.14 Understøttet brevindhold (DH)

Dokumenthåndteringen skal kunne understøtte anvendelsen af tekstelementer, variable data,                                      grafer,
tabeller, grafik, billeder.

Alternativ Id : 624
Kravtype : Funktionelt
Kravstiller : Dokumenthåndtering den : 2005 08 31
Status : Nyt      Prioritet :    Ansvarlig : Dokumenthåndtering




                                                                                                            1
                                                                                                  15.12.2005




7.5.15 Fritekst (DH)

I de situationer, hvor de på forhånd definerede dokumenter ikke dækker kunderådgiverens behov for
kommunikation overfor kunden, vil det være muligt at vælge et tomt dokument, hvor fritekst kan
tilføjes.

Udvalgte dokumenter vil have et fritekst felt, hvor mindre generelle tilføjelser kan gøres (fx "med tak
for behagelig telefonsamtale")
Alternativ Id : 625
Kravtype : Funktionelt
Status : Nyt      Prioritet :         Ansvarlig : Dokumenthåndtering




7.5.16 Hentning af fritekster (DH)

Dokumenthåndtering skal kunne hente eksternt lagrede fri-tekster i forskellige formater (fx word) og
påføre dem breve, hvor fritekst er tilladt


I tilfældet hvor en jurist/aktuar skal bruge tekster fra tidligere udfærdigede breve eller fx lovtekster, skal disse kunne hentes ind i de
dokumenttyper, hvor fritekst er tilladt.

Bemærkninger:
Fra Krav til Tværgående funktionalitet 260504 (internt projektdokument)
Alternativ Id : 626
Kravtype : Funktionelt
Kravstiller : Dokumenthåndtering den : 2005 08 31
Status : Nyt      Prioritet :       Ansvarlig : Dokumenthåndtering




                                                                                                                1
                                                                                  15.12.2005




8       I EKSTERN KOMMUNIKATION

    Ekstern Kommunikation


            Standardformat for dataudveksling(EK)


            Dataudveksling batch(EK)


            Dataudveksling online (EK)

            Leverancestyring (EK)


            Kustodefunktioner(EK)


            Logning (EK)



                                               Figure 8 I EKSTERN KOMMUNIKATION




8.1 Ekstern Kommunikation



8.1.1    Standardformat for dataudveksling(EK)

Domænet skal implementere internationale/offentlige anerkendte standarder og formater for dataudveksling.




                                                                                             1
                                                                                   15.12.2005




Alternativ Id : 700
Kravtype : Non-funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 23
Status : Nyt      Prioritet :   Ansvarlig : Ekstern Kommunikation




8.1.2      Dataudveksling batch(EK)

Systemet skal kunne sende og modtage dataleverancer 'batch' til/fra eksterne samarbejdspartnere -
som minimum skal de nuværende former for dataudveksling understøttes.

Alternativ Id : 701
Kravtype : Funktionelt
Kravstiller : Ekstern Kommunikation den : 2005 09 01
Status : Nyt      Prioritet :     Ansvarlig : Ekstern Kommunikation




8.1.3      Dataudveksling online (EK)

Systemet skal kunne sende, modtage og hente data 'on-line' (push og pull) til/fra/hos eksterne
samarbejdspartnere (fx via webservices). Eksempler på eksterne parter: Pensionsinfo, e-Boks,
NemKonto, e-Faktura, e-Indkomst, Virk.dk etc.

   Alternativ Id : 702
   Kravtype : Funktionelt
Kravstiller : Ekstern Kommunikation den : 2005 09 23
Status : Nyt      Prioritet :     Ansvarlig : Ekstern Kommunikation




   8.1.4              Leverancestyring (EK)

   En udgående leverance skal kunne genudsendes ved fejl i tidligere dataindhold. Oplysninger om
      forløbet skal logges.

   En indgående leverance skal kunne modtages på ny ved fejl i tidligere dataindhold. Oplysninger
      om forløbet skal logges.

   En leverance - både ind- og udgående - skal kunne annulleres. Oplysninger om forløbet skal
      logges.

Validering skal foretages ved ind- og uddata (sammentælling, format mv.). Der skal foreligge
forretningsgange for hvert enkelt scenarie på hver enkelt leverance ud og ind.

Alternativ Id : 703




                                                                                           1
                                                                        15.12.2005


Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 10 04
Status : Nyt       Prioritet :    Ansvarlig : Ekstern Kommunikation




8.1.5     Kustodefunktioner(EK)

        Systemet skal kunne vedligeholde (opret, ret, slet, vis) de forskellige leverancetyper, vi skal
        kunne udveksle mellem eksterne samarbejdspartnere( Eksempelvis: CPR, Jyske Bank, E-boks
        etc.) og ATP-domæner, herunder oplysninger om:
                       leverancenavn/leverancetype
                       modtager/afsender
                       max ekspeditionstid
                       kanal/medie
                       format
                       link til evt. scheduleringsværktøj
                       frekvens
                       kalender for modtagelse/afsendelse



Alternativ Id : 704
Kravtype : Funktionelt
Kravstiller : Ekstern Kommunikation den : 2005 09 23
Status : Nyt      Prioritet :     Ansvarlig : Ekstern Kommunikation




8.1.6     Logning (EK)

Data om kommunikationen mellem domænet og tredjepart skal logges. Logdata skal kunne benyttes
efterfølgende af DW-domænet.

Alternativ Id : 705
Kravtype : Funktionelt
Kravstiller : Krav - Workshop den : 2005 09 23
Status : Nyt       Prioritet :    Ansvarlig : Ekstern Kommunikation




                                                                                  1
                                15.12.2005




9   J JURIDISK AFDELING(JURS)




                                        1
                                                   15.12.2005



Lovmæssige krav


       Dataopbevaringstid(JURS)


       Fortrolighed(JURS)


       Overholdelse af lovgivning -generelt(JURS)


       Autencitet-Integritet-Uafviselighed(JURS)


       Arbejdsmiljøkrav(JURS)


       Elektronisk kommunikation(JURS)


       Sporbarhed(JURS)


       Egenacces(JURS)


       Aktindsigt(JURS)


       Effektive journalsystemer(JURS)


       Fristregler(JURS)


       Arkivering(JURS)


       Partshøring(JURS)


       Opbevaringspligt/sagsdokumentation(JURS)


       Skriftlighed(JURS)


       Behandlingssikkerhed(JURS)
                                                           1
                                                                                             15.12.2005



                                                      Figure 9 J JURIDISK AFDELING(JURS)




9.1 Lovmæssige krav



9.1.1    Dataopbevaringstid(JURS)

Der skal udfærdiges et dokument vedrørende dataopbevaring i forbindelse med forældelsesfrister.
     Hvor længe skal de enkelte dokumenttyper opbevares og hvornår skal de slettes. Det samme
     gælder for sager. Sager og dokumenter udgør sædvanligvis et hele og er derfor underlagt
     identiske bevarings- og sletningskrav.

     Hovedregel: Oplysninger skal kunne gemmes for den enkelte ordning med differentieret opbevaringsperiode - efter
      omstændighederne i op til xx år efter længstlevende ægtefælles død
     Den enkelte ordning har pligt til at slette data, når behovet for data ikke længere er tilstede.
     Ved behov forstås, at der kan rejses berettigede krav mod ordningen.
Alternativ Id : 800
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :       Ansvarlig : JURS

Accept Kriterie :
At data på enkel og betryggende vis kan genskabes og i øvrigt slettes i sin helhed. Det vil nok være hensigtsmæssigt med
early warning i forhold til sletningsfrister.

9.1.2    Fortrolighed(JURS)

For ATP koncernen vil fx medlemmer være kendt i flere ordninger. Det kan være én registrering under
respekt for persondataloven og forbuddet mod krydssubsidiering (en ikke-lovbunden ordning har kun
adgang til en oplysningstype, hvis den i forvejen er offentlig tilgængelig, og den ikke-lovbundne
ordning har aftale med og betaler til udbyderen for disse data; eksempelvis har PS-ordningerne aftale
med CPR som forudsætning for CPR-data i ATP's lønmodtagerregister . Endvidere er det væsentligt,
at information der i fortrolighed er givet til én ordning eller over for én PS kunde (fx et hemmeligt
telefonnummer eller en hemmelig adresse) holdes lokalt for denne og ikke videreformidles til de
øvrige ordninger eller PS Kunder.


     Hovedregel: en ordnings oplysninger må kun behandles inden for ordningen.
     Modif: nogle stamdata (f.eks. offentlig tilgængelig adresse fra VIRK.) kan videregives mellem ordninger under forudsætning af, at
      ovennævnte krav er iagttaget.
     Undtagelser: lovregler, der giver særlig hjemmel til videregivelse mellem ordninger.
Alternativ Id : 801
Kravtype : Non-funktionelt




                                                                                                          1
                                                                                                     15.12.2005


Kravstiller : Krav - RFI den : 2005 09 19
Status : Nyt       Prioritet :     Ansvarlig : JURS




9.1.3     Overholdelse af lovgivning -generelt(JURS)

Systemet skal til enhver tid opfylde EU-ret og dansk lovgivning i øvrigt med relevant for ATP-
koncernens forretningsområder, herunder Persondataloven og Bogføringsloven, samt ethvert
offentligt direkte eller indirekte fastsat krav til livsforsikringsselskaber og pensionskassers drift,
skadesforsikringsvirksomhed og bankvirksomhed.

Alternativ Id : 802
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.4     Autencitet-Integritet-Uafviselighed(JURS)

ATP's juridiske krav til IT-systemer kan i sit udgangspunkt sidestilles med de krav, der på det
    administrative område stilles til forsvarlig forvaltning og forsikringsvirksomhed.

Dette omfatter følgende fokus-områder:

Autenticitet
Ved autenticitet (også benævnt ægthed) forstås sikkerheden for, at informationer skabes og registreres på en sådan måde, at den
      afgivne kilde vedstår sig indholdet af en given informationsmængde.

Integritet
Ved integritet forstås sikkerheden for, at den informationsmængde, der modtages/registreres, er forblevet uændret fra det tidspunkt,
       hvor den, der angives at vedstå sig indholdet, har markeret sin vedståelse. Integriteten sikres således ved, at en information ikke
       er blevet ændret uretmæssigt i transmission eller under opbevaring.

Uafviselighed
Ved uafviselighed forstås sikkerheden for, at den, der har vedstået sig indholdet, ikke efterfølgende kan fragå sig denne vedståelse -
      eller med andre ord at sikkerheden for, at det efterfølgende kan bevises, at afsenderen har vedstået sig indholdet.

Kun når alle tre betingelser (autenticitet, integritet og uafviselighed) for en given information er opfyldt, kan der disponeres i tillid til
      informationen.
Alternativ Id : 803
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt       Prioritet :        Ansvarlig : JURS




9.1.5     Arbejdsmiljøkrav(JURS)

Arbejdsmiljøkrav




                                                                                                                    1
                                                                          15.12.2005



Ethvert IT-system skal til en hver tid opfylde gældende arbejdsmiljøkrav til skærmflader,
    betjeningsfunktioner mv. ATP's SIU har formuleret deltaljerede kriterier herfor.
Alternativ Id : 804
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.6   Elektronisk kommunikation(JURS)

De senere års udvikling i kommunikationen indebærer efterhånden en pligt for myndigheden til at
stille sikker elektronisk kommunikation til rådighed for borgeren sikret via sikre forbindelser og digital
signatur.

Alternativ Id : 805
Kravtype : Funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.7   Sporbarhed(JURS)

Dette hensyn understøtter det generelle princip om autenticitet - altså at ophavet til alle data og
eventuelle senere ændringer heri entydigt er identificerbare med hensyn til hvem, hvornår, hvor og
hvordan data er dannet.

Alternativ Id : 806
Kravtype : Funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.8   Egenacces(JURS)

Enhver borger har i henhold til persondataloven ret til at anmode om egenacces hvorved forstås
adgang til at gøre sig bekendt med de oplysninger, myndigheden og/eller selskabet ”behandler” om
vedkommende. ”Behandler” skal forstås bredt og omfatter enhver oplysning i myndighedens og/eller
virksomhedens besiddelse, der relaterer sig til vedkommende. Borgeren har ret til efter
omstændighederne at forlange retmæssig korrektion.

Alternativ Id : 807
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




                                                                                    1
                                                                      15.12.2005



9.1.9   Aktindsigt(JURS)

I henhold til forvaltningsloven har enhver borger ret til ”aktindsigt” i sin sag - opbevares denne
elektronisk omfatter aktindsigten tillige den indskannede sag. En begæring om aktindsigt skal som
udgangspunkt håndteres hurtigt og enkelt - uden bearbejdning af sagen/data.

Alternativ Id : 808
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.10 Effektive journalsystemer(JURS)

Reglerne om aktindsigt fodrer, at myndigheden blandt andet skal oprette effektive journalsystemer -
dette betyder, at ethvert indgået og udgået brev på ”sagen” skal være journaliseret og kunne
genskabes/fremfindes. Journaliseringsfunktionen bør også understøtte journalisering af interne
sagsakter. E-post-systemer bør derfor være integreret med journaliseringssystemet. Tilsvarende kan
meget snart komme på tale i forhold til telefonsamtaler, der er omfattet af notatpligten i
offentlighedsloven og derfor skal fremgå af ”sagen”.

Alternativ Id : 809
Kravtype : Funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.11 Fristregler(JURS)

Visse klager skal være modtaget af myndigheden inden for en vis frist. I det omfang, der er adgang til
at klage over sig sag via elektronisk post, er det vigtigt, at myndigheden på dokumenterbart grundlag
kan angive, på hvilket tidspunkt og på hvilken (relevant) IP-adresse, klagen er modtaget.

Alternativ Id : 810
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.12 Arkivering(JURS)

Det er økonomisk hensigtsmæssigt at planlægge med elektronisk dokumentopbevaring (arkivering),
     da pligtmæssig, senere papirarkivering i Statens Arkiver er meget bekostelig, hvis sagerne er i
     fysisk format.




                                                                                1
                                                                       15.12.2005



Det bemærkes, at Statens Arkiver skal godkende elektroniske arkivsystemer, der senere skal tilgå
     Statens Arkiver.
Alternativ Id : 811
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.13 Partshøring(JURS)

Anvender myndigheden oplysninger ved behandlingen af en borgers sag, som han ikke er bekendt
med, skal borgeren partshøres over disse oplysninger, inden afgørelse træffes.

Alternativ Id : 812
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.14 Opbevaringspligt/sagsdokumentation(JURS)

Myndigheden har pligt til at dokumentere sin sagsbehandling og opbevare relevant
sagsdokumentation sålænge som forældelsesregler mv. gør det påkrævet.

Alternativ Id : 813
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.15 Skriftlighed(JURS)

Visse dokumenter skal foreligge i ”skriftlig form” - indlagres skriftlige dokumenter i elektronisk form
     skal de ovenstående principper om autenticitet, integritet og uafviselighed iagttages for sådanne
     indlæste dokumenter - ikke alle dokumenter kan lovligt overlades til elektronisk håndtering.
Alternativ Id : 814
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




9.1.16 Behandlingssikkerhed(JURS)

Myndigheden har pligt til at foretage sikker databehandling til imødegåelse af forvanskning, sletning,



                                                                                 1
                                                        15.12.2005



utilsigtet videregivelse samt brud på fortroligheden.

Alternativ Id : 815
Kravtype : Non-funktionelt
Kravstiller : JURS den : 2005 09 19
Status : Nyt      Prioritet :    Ansvarlig : JURS




                                                                1
                             15.12.2005




10 K INTERN REVISION(IREV)




                                     1
                                                 15.12.2005



Revisionsmæssige krav



            Overordnede krav(IREV)


            Fortrolighed(IREV)
        1

            Tilgængelighed(IREV)
        1

            Kontrol- og transaktionsspor(IREV)
        1

            Integritet(IREV)
        1

            Uafviselighed(IREV)
        1

            Fuldstændighed generelt(IREV)


            Fuldstændighed ved inddata(IREV)
        1

            Fuldstændighed ved funktionter og
        1   registre(IREV)
            Fuldstændighed ved uddata(IREV)
        1

            Nøjagtighed vedr. inddata(IREV)
        1

            Nøjagtighed vedr. funktioner og
        1   registre(IREV)
            Nøjagtighed vedr. uddata(IREV)
        1

            Rettidigheden vedr. inddata(IREV)
        1

            Rettidigheden vedr. funktioner og
        1   registre(IREV)
            Rettidigheden vedr. uddata(IREV)
        1

            Godkendte
        1   transaktioner-Generelt(IREV)

            Godkendte transaktioner vedr.
        1   inddata(IREV)
            Godkendte transaktioner vedr.
        1   funktioner og registre(IREV)

            Godkendte transaktioner vedr.
        1   uddata(IREV)
                                                         1
                                                                                          15.12.2005



                                                      Figure 10 K INTERN REVISION(IREV)




10.1 Revisionsmæssige krav



10.1.1 Overordnede krav(IREV)

Vi forudsætter, at de generelle krav til IT-systemer er opfyldt.

Eksempelvis (ikke udtømmende):
     at den nødvendige systemdokumentation er ajour og umiddelbart til at læse
     at systemet omfattes af formaliserede (inkl. vejledninger) elektroniske change managementprocedurer,
     at der er etableret standard for godkendelse af test til produktion
     at drift afvikling kan ske i et ATP valgt sceduleringsværktøj
     at drift kun gennemføres på godkendte programmer
     at drift kun gennemføres af produktionsmedarbejdere (adskillelse mellem udvikling og drift)
     at der etableret problemmanagement procedurer, herunder
     at der er fastlagte procedurer til korrektion af data (formentlig anvendelse af engangsprogrammer)
     at programmer og data gemmes, inklusive versionsstyring
     at der er den nødvendige logning på driftsafviklinger
     at såvel det enkelte program som det samlede systemkompleks kan overvåges
     at database/tabelstruktur gør det muligt for brugerne at lave egne dataudtræk ved hjælp standard værktøjer (SAS, QMF, IDEA,
      Datawarehouse eller lignede værktøjer)
Alternativ Id : 900
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt        Prioritet :        Ansvarlig : Intern Revision




10.1.2 Fortrolighed(IREV)

Det skal sikres, at information kun er tilgængelig for dem der er autoriseret til at have adgang. Dette
gælder internt i huset (kravet må være, at systemet skal kunne administreres i TIM/TAM, hvilket også
gælder systemets eventuelle interne rettighedsmoduler) og ved ekstern kommunikation (l kryptering,
fastopkoblede linier mv.).

Alternativ Id : 901
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




                                                                                                       1
                                                                                               15.12.2005



10.1.3 Tilgængelighed(IREV)

At opnå en høj tilgængelighed ved høj drifts- og fysisk sikkerhed med høje oppetider og minimeret
     risiko for nedbrud.
Tilgængelighed dækker også rettidighed. Definitionen i standarden er: Sikring af, at autoriserede
     brugere skal have adgang til information og komponenter på forlangende.
Alternativ Id : 902
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision

Accept Kriterie :
Anvendelse af ATP's driftsværktøjer til måling af tilgængelighed.

10.1.4 Kontrol- og transaktionsspor(IREV)

Samtlige spor skal være online-tilgængelige.
Konkret skal der stilles et udsøgningsværktøj til rådighed, således at oplysninger fra sporene kan hentes frem til
revisionsformål.
ATP skal kunne gennemgå sporene for udvalgte tidsrum, ligesom ATP skal kunne udsøge dele af et spor på grundlag af
andre forhold. Oplysninger i den del af sporet, som gennemgås, skal præsenteres på en overskuelig form med mulighed
for på anfordring at få præsenteret alle detaljer.
Udsøgningsværktøjet skal endvidere give mulighed for at definere standardudtræk og rapporter.

Vi har et ønske om at kunne bruge IDEA, mens andre vil bruge SAS, QMF osv. En løsning kunne også være Datawarehouse. En
meget vigtig forudsætning er derfor, at database-/tabelstruktur er så enkel og så velbeskrevet, at det umiddelbart er muligt at foretage
udtræk med et hvilket som helst standard udtræksværktøj uden medvirken fra IT afdelingen.
Alternativ Id : 903
Kravtype : Funktionelt
Kravstiller : SP den : 2005 09 18
Status : Nyt      Prioritet : 1      Ansvarlig : Intern Revision

Accept Kriterie :
At det kan lade sig gøre. Det må være muligt for leverandøren at demonstrere dette på et allerede eksisterende system.

10.1.5 Integritet(IREV)

At opnå en pålidelig og korrekt funktion af informationssystemerne med minimeret risiko for ukorrekt datagrundlag, for
eksempel som følge af menneskelige og systemmæssige fejl samt udefrakommende hændelser.

Definitionen af integritet er i følge standarden: ”Safeguarding accuracy and completeness of information and processing methods”.
Integritet dækker også fuldstændighed, nøjagtighed samt omstændighederne der tilvejebragte informationen.
Alternativ Id : 904
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1        Ansvarlig : Intern Revision




10.1.6 Uafviselighed(IREV)

At sikre fornødne kontrolspor er tilstede på et passende niveau, således gennemførte transaktioner



                                                                                                             1
                                                                                        15.12.2005



ikke kan benægtes.

For at sikre overholdelse at såvel persondataloven som bogføringsloven samt revisionskrav opererer ATP IT-arkitektur
med tre typer obligatoriske logs:
    Kontrolspor
    Transaktionsspor
    Sikkerhedslog

Kontrolspor
Kontrolsporet skal skabe vertikal sammenhæng og afspejle de kontrolforanstaltninger der har været anvendt. Generelt
skal kontrolforanstaltningerne sikre at transaktioner udføres nøjagtigt, at der er sammenhæng mellem input og output og
at eventuelle fejl kan opdages og spores.

Følgende er information der skal fremgå af kontrolsporet:
    Hvem der har udført en handling (typisk fællesbruger-ID)
    Hvornår en handling er udført (timestamp)
    Hvilken klient der har initieret handlingen
    I hvilken sammenhæng (portal applikation, workflow, sagsbehandling) handlingen er blevet udført

Hvis der foretages kontroller under behandlingen skal resultatet logges så det fremgår af kontrolsporet at der er foretaget
en kontrol samt hvad resultatet af kontrollen var. Hvis en komponent eksempelvis kontrollerer gyldigheden af en
udbetalingsautorisation i et andet domæne i forbindelse med en udbetaling skal kontrollen og output fra kontrollen logges.

Vertikal sammenhæng i kontrolsporet betyder at en handling kan tilbageføres til en sag. Handlingens kontrolspor skal
derfor indeholde en reference til den sag eller proces der har initieret handlingen. Det forventes at handlinger i stor stil
udføres ved servicekald gennem message brokeren. I de tilfælde skal broker meddelelserne indeholde de nødvendige
informationer således at backend komponenter kan logge det nødvendige kontrolspor som defineret ovenfor.

Transaktionsspor
Transaktionssporet sikrer overblik over sammenhængen mellem de forskellige deloperationer der indgår i en samlet
sagsbehandling.
Kontrol- og transaktionsspor skal gemmes i henhold til bogføringslovens bestemmelser såfremt der er tale om posteringer.
I
disse tilfælde skal loggen gemmes i 6 år således at det løbende år + 5 år er indeholdt. Hvis ikke der foretages posteringer
er der ikke krav om kontrol- og transaktionsspor. Netop denne regel kan svær at håndtere i et SOA (Service Orienteret
Arkitektur) miljø, hvor services kan indgå i en større sagsbehandling på en måde der er ukendt på udviklingstidspunktet.
Det skal derfor ved design sikres at en kombination af serviceoperationer, der medfører en postering, altid logger kontrol-
og transaktionsspor.

Transaktionssporet skal afspejle den faktiske transaktion. Det vil sige at rollback forløb med eller uden kompenserende
handlinger skal kunne sammenkædes med resten af transaktionen. Loggen skal som hovedregel altid korrekt afspejle de
services der er udført eller tilbageført.

Sikkerhedslog
Sikkerhedsloggen skal indeholde generelle kontroller der udføres med henblik på autorisation og særligt ved adgang til
adgang der er underlagt persondataloven. Ved adgang til denne type data skal følgende logges uanset om der
forespørges eller opdateres:
    Hvem der har haft adgang - typisk fællesbruger-ID for sagsbehandler eller slutbruger
    Hvornår adgangen er foretaget (timestamp)
    Hvilken klient der har initeret handlingen
    I hvilken sammenhæng (portal applikation, workflow, sagsbehandling) handlingen er blevet udført

Loggen skal kunne bekræfte at en bruger eller et system har haft autoriseret og relevant adgang til de pågældende data.




                                                                                                     1
                                                                                         15.12.2005


Sikkerhedsloggen skal gemmes i 6 måneder hvorefter den slettes.
Alternativ Id : 905
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision

Accept Kriterie :
Der kan testes på de felter, der indgår i Kontrol- og transaktionsspor samt sikkerhedsloggen.

10.1.7 Fuldstændighed generelt(IREV)

Det skal sikres,
     at der ikke mistes data ved systemnedbrud på f. eks. MQ/brokker/dataliner
     at der er afstemmelighed i programmer/grænseflader, mellem programmer i systemet, mellem systemer, mellem ATP og
      eksterne leverandører/kunder (herunder kvitteringsprocedurer)
Alternativ Id : 906
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet :      Ansvarlig : Intern Revision




10.1.8 Fuldstændighed ved inddata(IREV)

Fuldstændighed skal sikres ved, at alle data registreres i systemet med henblik på senere behandling.

Alternativ Id : 907
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.9 Fuldstændighed ved funktionter og registre(IREV)

Fuldstændighed kan sikres ved forskellige typer kontroller, der eksempelvis indebærer afstemning
mellem antal registrerede og behandlede transaktioner. Herved sikres det at alle registrerede
transaktioner behandles én gang.
Procedurerne/kontroller skal være maskinelle
Alternativ Id : 908
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.10             Fuldstændighed ved uddata(IREV)

Fuldstændighed, dvs., sikring af at alle uddatafiler og udskrifter findes, kan ske på grundlag af en
entydig identifikation af uddata i form af fortløbende numre, datoer, hvis uddata eksempelvis skal



                                                                                                   1
                                                                                      15.12.2005



genereres med faste intervaller (dagligt, ugenligt etc.). For at denne fuldstændighedskontrol er
effektiv, skal der være etableret procedurer, der følger op på, om alle uddatafiler/udskrifter
fremkommer som forventet.

Procedurerne/kontroller skal være maskinelle
Alternativ Id : 909
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.11           Nøjagtighed vedr. inddata(IREV)

Nøjagtighed kan eksempelvis sikres ved valideringskontroller i forbindelse med indtastningen.

Derudover skal der i systemet opbygges mekanismer til at sikre, at vi ikke 'taber' transaktioner.
Alternativ Id : 910
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.12           Nøjagtighed vedr. funktioner og registre(IREV)

Nøjagtighed i databehandlingen kan blandt andet sikres ved procedurer, der sikrer, at det er de
korrekte versioner af transaktioner der benyttes, og at de benyttes i den korrekte rækkefølge.

Procedurerne skal være maskinelle.
Alternativ Id : 911
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.13           Nøjagtighed vedr. uddata(IREV)

Procedurer, der eksempelvis sikrer, at forudsætninger for udskriftens/uddatafilens nøjagtighed er til
stede.
Procedurerne skal være maskinelle
Alternativ Id : 912
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




                                                                                                    1
                                                                                     15.12.2005



10.1.14           Rettidigheden vedr. inddata(IREV)

Rettidigheden indebærer, at data registreres snarest muligt efter, at forhold der er til grund til
registrerende, foreligger. Endvidere skal inddata registreres i korrekt tidsmæssig rækkefølge.

Definitionen af ”snarest muligt” afhænger af den enkelte transaktion fra de enkelte
forretningssystemer. Eksempelvis skal en fondshandel registreres så snart som handlen er indgået,
mens registrering af anmodning af udbetaling af LD midler formentlig kan vente et par dage, afhængig
af service aftale med LD.
Alternativ Id : 913
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.15           Rettidigheden vedr. funktioner og registre(IREV)

Rettidig databehandling er afhængig af driftsafviklingen i såvel realtids- som batchopdateringer.

Alternativ Id : 914
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.16           Rettidigheden vedr. uddata(IREV)

Data generes eksempelvis efter en fastplan og procedurerne for distribution følger foruddefinerede kanaler.

Alternativ Id : 915
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.17           Godkendte transaktioner-Generelt(IREV)

Der vil være en række tilfælde, hvor der kræves forskellige kontrolhandlinger.
Det er vigtigt, at kontrollerne fastlægges på tværs af systemer og systemernes enkelte funktioner.

Hver transaktion skal derfor vurderes i hvilket omfang den skal underkastes kontrol. Det er vigtigt, at
der kan skabes en varieret kontrolstruktur på transaktionerne. Variationen gælder eksempelvis
beløbsstørrelser, 1. og 2. sagsbehandlerinvolvering, periodevis øgning/lempelse af kontrol, den kunde
transaktionen udføres for (PensionDanmark stiller måske andre krav end ATP, som stiller andre krav
en LD osv.), der er transaktioner, som man må gennemføre i enkelte moduler, men for eksempel ikke



                                                                                                    1
                                                                                     15.12.2005



på tværs af moduler osv.

Kontrollerne kunne for eksempel være en tabel (eller flere afhængig af den løsning, der vælges), som
specificerer kravene til de enkelte transaktioner. Der bør være tale om en parameterstyret (i dette
eksempel) tabel som kan vedligeholdes af brugerne, hvor én bruger registrerer parameteren, som en
anden bruger godkender. ”Tabellen” skal være versionsstyret.

Kontrollerne skal kunne knyttes til de enkelte transaktioner og ikke sikres adgangstildeling til
funktioner (gennemskærmbilleder). Dette vil lette administrationen af tildelingen af rettigheder til
brugerne.
Alternativ Id : 916
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.18           Godkendte transaktioner vedr. inddata(IREV)

Godkendelsen indebærer, at de registrerede data skal være gyldige og transaktionerne skal vedrøre
virksomheden. Transaktionerne skal være autoriserede efter fastlagte kriterier.

Alternativ Id : 917
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.19           Godkendte transaktioner vedr. funktioner og registre(IREV)

Godkendelse af data sikres i en lang række tilfælde af generelle forhold, eksempelvis ved opdeling i adgangstilladelser til
udvikling/drift/brugerfunktioner.

Alternativ Id : 918
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18
Status : Nyt       Prioritet : 1    Ansvarlig : Intern Revision




10.1.20           Godkendte transaktioner vedr. uddata(IREV)

Sikring af godkendte uddata sker eksempelvis ved forudbestemte analyser af data. Eksempelvis kan i øvrigt behandlede
og godkendte data sendes i work flow på grund af størrelse eller andre karakteristika. Suppleres.

Alternativ Id : 919
Kravtype : Non-funktionelt
Kravstiller : Intern Revision den : 2005 09 18




                                                                                                  1
                                                             15.12.2005


Status : Nyt   Prioritet : 1   Ansvarlig : Intern Revision




                                                                     1
                                                                                                        15.12.2005




11 L IT-ARKITEKTUR(ITAR)

Applikationsdesign(ITAR)                                Sikkerhed(ITAR)                                Test(ITAR)


       Komponentbaseret og serviceorienteret(ITAR)           X - Sikkerhedsprincipper(ITAR)                  Test i hht ATP_s testdisciplin(ITAR)
  1                                                      1                                               1

       System opdelt i komponenter(ITAR)                     X - Sikkerhedsarkitekturen baseret på           Funktionel test(ITAR)
  2                                                      1   RBAC(ITAR)                                  1

       Samme begreber overalt(ITAR)                          Autenticitet(ITAR)                              Grænsefladetest(ITAR)
  2                                                      1                                               1

                                                             Konfidentialitet(ITAR)                          ATPs testmanagementværktøj(ITAR)
       Tilgængelighed - findes også som Driftskrav
       (ITAR)                                            1                                               1
  1
                                                             Uafviselighed(ITAR)
       Løs kobling mellem domæner og eksterne                                                                Leverancer(ITAR)
                                                         1
  3    samarbejdspartnere(ITAR)                                                                          1
                                                             Autorisation(ITAR)                              Fejlhåndtering(ITAR)
       Effektiv håndtering, fremsøgning og lagring af    1
       information og data på tværs af ATP(ITAR)                                                         1
  2
                                                             Formel autorisationsprocedure- og
       Ingen forretningsregler i                         2   arbejdsgang(ITAR)
  1    brugergrænseflade(ITAR)
                                                             Begrænsning af brugernes adgange(ITAR)
       X - Løsning skal passe ind i ATP_s Teknologi      2
  2    model og Teknisk infrastrukturmodel(ITAR)

       Løsnings dokumentation(ITAR)
  2
                                                             Stikprøvekontrol af systemloggen(ITAR)
       X - Historik(ITAR)                                2
  1
                                                             Supplerende kontroller(ITAR)
                                                         2
Integration(ITAR)
                                                             Krav til ekstern kommunikation(ITAR)
                                                         1
      Integration mellem købe-systemer og
 1    egenudviklede komponenter (ITAR)                       Selvbetjening via portal(ITAR)

      Sporbarhed på tværs af systemer(ITAR)
 1                                                           Overholdelse af sikkerhedsstanderder og
                                                         1   -lovgivning(ITAR)



                                                                  Figure 11 L IT-ARKITEKTUR(ITAR)




11.1 Applikationsdesign(ITAR)



11.1.1 Komponentbaseret og serviceorienteret(ITAR)

Specifikationer for services og deres operationer kontrolleres mod de kriterier i checklisterne for service og
komponentspecifikationer fra ATP's udviklingsmodel.




                                                                                                                           1
                                                                                       15.12.2005


Udstillings teknologi matches op mod de teknologier som er specificeret som ATP's præfererede.
Alternativ Id : 1000
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Specifikationer for services og deres operationer kontrolleres mod de kriterier i checklisterne for service og
komponentspecifikationer fra ATP's udviklingsmodel.
Udstillings teknologi matches op mod de teknologier som er specificeret som ATP's præfererede.

11.1.2 System opdelt i komponenter(ITAR)

Det er et krav at systemet er struktureret i komponenter som indkapsler data og funktionalitet og som har veldefinerede
grænseflader, så senere videreudvikling kun vil berøre en begrænset del af systemet.

Alternativ Id : 1001
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 2   Ansvarlig : ITAR

Accept Kriterie :
Specifikationer for komponenter og deres operationer kontrolleres mod de kriterier i checklisterne for
komponentspecifikationer fra ATP's udviklingsmodel.

11.1.3 Samme begreber overalt(ITAR)

Det er et krav at samme begreber har samme navne og betydning overalt i systemet.

Alternativ Id : 1002
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 09 16
Status : Nyt       Prioritet : 2   Ansvarlig : ITAR

Accept Kriterie :
Der findes en informationsmodel så som beskrevet i ATP's udviklingsmodel.
Systemets services skal udtrykke deres funktionalitet i en underliggende informationsmodel.

11.1.4 Tilgængelighed - findes også som Driftskrav (ITAR)

I det grundlæggende design skal der være taget højde for, at applikationer (specielt Portal-service, men også online) og
hardwaresystemer skal være tilgængelige 24 timer i døgnet året rundt dvs. 24/7/365.

Alternativ Id : 1003
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 09 16
Status : Nyt       Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Leverandøren skal anføre undtagelser fra 24 timers designkrav




                                                                                                   1
                                                                                    15.12.2005



11.1.5 Løs kobling mellem domæner og eksterne samarbejdspartnere(ITAR)

Koblingen mellem løsningen til ATP's eksterne samarbejdspartnere skal være så løs som muligt

Alternativ Id : 1004
Kravtype : Funktionelt
Kravstiller : Krav-PIXI den : 2005 09 16
Status : Nyt       Prioritet : 3   Ansvarlig : ITAR

Accept Kriterie :
Er kobling mellem systemet og omverden realiseret via veldefinerede interfaces.

11.1.6 Effektiv håndtering, fremsøgning og lagring af information og data på tværs af ATP(ITAR)

Systemløsningen skal medvirke til at sikre en mere effektiv håndtering, fremsøgning og lagring af information og data på
tværs af ATP gennem konsistent anvendelse af metadata (data om data).

Alternativ Id : 1005
Kravtype : Funktionelt
Kravstiller : Krav-PIXI den : 2005 09 16
Status : Nyt       Prioritet : 2   Ansvarlig : ITAR

Accept Kriterie :
Kvaliteten af metadata kontrolleres.

11.1.7 Ingen forretningsregler i brugergrænseflade(ITAR)

Den udstillede funktionalitet (via services) må ikke stille krav til anvenderen omkring implementering af bestemte
forretningsregler. F.eks. må det ikke kræves at bestemte valideringer er foretaget inden anvenderen bruger bestemte
services.

Alternativ Id : 1006
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Service specifikationer viser at alle forretningsregler håndhæves i service implementeringen.

11.1.8 X - Løsning skal passe ind i ATP_s Teknologi model og Teknisk infrastrukturmodel(ITAR)

Løsningen skal passe ind i de teknologi- og teknisk infrastrukturmodeller som fremgår af ATP's
Enterprise Arkitektur

Alternativ Id : 1007
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 2   Ansvarlig : ITAR

Accept Kriterie :
Løsningens tekniske implementeringsmodel (som defineret i ATP's Enterprise Arkitektur) passer ind i ATP's teknologi og




                                                                                                1
                                                                                                   15.12.2005


tekniske infrastrukturmodel.

11.1.9 Løsnings dokumentation(ITAR)

Løsnings dokumentation skal svare til de relevante (blivende) artefakter som er defineret i ATP's udviklingsmodel. Hvilke
artefakter er relevante i forhold til fokus på forretning, system, løsning eller realisering afhænges af efterspurgte løsning

Alternativ Id : 1008
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 2   Ansvarlig : ITAR

Accept Kriterie :
Dokumentationen kontrolleres for de af ATP udpegende relevante artefakter.

11.1.10             X - Historik(ITAR)

Der skal overalt i Systemet være fuld historik, så situationen pr. en given dato som registreret på et givet tidspunkt altid
kan fremstilles.
Historikken skal bruges aktivt, fx så man kan have behandlinger eller beregninger, der direkte bruger et sortiment af
historikversioner.
Alternativ Id : 1009
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Dokumentationen kontrolleres for tilstedeværelsen af historik elementer.

11.2 Integration(ITAR)



11.2.1 Integration mellem købe-systemer og egenudviklede komponenter (ITAR)

Mulighed for at integrere egenudviklede komponenter eller komponenter fra tredje mand.
Integration foregår i henhold til de krav, der er opstillet for systemer i System Integrations Politikken (SIP).

Alternativ Id : 1010
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 09 16
Status : Prioritet : 1    Ansvarlig :

Accept Kriterie :
Proof-points hvor integration jævnfør principper og metoder i SIP gennemføres.

11.2.2 Sporbarhed på tværs af systemer(ITAR)

Integrationen af de forskellige systemer skal foretages, så der som standard er fuld sporbarhed på
tværs af systemer.
Enhver transaktion skal - uanset eventuel fjern oprindelse - stemples med udførende og være



                                                                                                                   1
                                                                                    15.12.2005



uafviselig.
Såvel integrationen i sin helhed, som de indgående systemer skal leve op til revisionskravene for
sikkerhed og dokumentation. Almindelige systemrevisionskrav jf. bogføringsloven skal umiddelbart
kunne opfyldes.
Uddybning: Designprincipper vil beskrive krav til registrering af diverse sporbarheds-oplysninger og
deres registreringspunkter.
Alternativ Id : 1011
Kravtype : Funktionelt
Kravstiller : Krav - RFI den : 2005 09 16
Status : Nyt       Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Proof-points hvor krav til sporbarhed afprøves i henhold til designprincipper.

11.3 Sikkerhed(ITAR)



11.3.1 X - Sikkerhedsprincipper(ITAR)

ATP har valgt at implementere de fundamentale sikkerhedsservices i infrastrukturen. Software arkitekturen skal således
bygge på infrastruktur elementer for at opnå den fornødne sikkerhed.
ATP's SOA strategi betyder at sikkerhedsarkitekturen skal være tværgående og være loyal overfor fundamentale
principper, der gør det muligt at opnå en åben og fleksibel struktur.
Det er vigtigt at systemerne baseres på en tværgående sikkerhedsarkitektur og de politikker der er defineret heri. Dette
sikrer et ensartet og gennemsigtigt samlet system.

Tekniske komponenter som indgår infrastrukturen er flg.:
Tivoli Access Manager
LDAP
Active Directory
Tivoli Identity Manager
(Federal Identity Manager ) findes ikke p.t.

Nye systemer skal anvende de eksisterende sikkerhedskomponenter I infrastrukturen således at der ikke introduceres nye
sikkerhedskomponenter eller principper.
Alternativ Id : 1012
Kravtype : Funktionelt
Kravstiller : SIKA/ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1  Ansvarlig : SIKA/ITAR

Accept Kriterie :
Der findes en klar beskrivelse af hvordan løsningen anvender de nævnte komponenter i ATP's sikkerheds infrastruktur og
der redegøres i løsningsbeskrivelsen kort for at der ikke er behov for yderligere sikkerhedskomponenter.

11.3.2 X - Sikkerhedsarkitekturen baseret på RBAC(ITAR)

Tildeling af brugerrettigheder baseres på RBAC filosofien (Role Based Access Control). I ATP's heterogene miljø med
forskellige systemer er det vigtigt at sikkerheden styres i henhold til en central og tværgående sikkerhedsdefinition.

Alternativ Id : 1013




                                                                                                1
                                                                                            15.12.2005


Kravtype : Funktionelt
Kravstiller : SIKA/ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1  Ansvarlig : SIKA/ITAR

Accept Kriterie :
Der er redegjort for at løsningen kan operere i overensstemmelse med ATP's rollemodel.
Der er redegjort for hvordan løsningen integreres med rollerne i TIM og såfremt løsningen har en intern
rettighedsdatabase redegøres der yderligere for hvorledes informationen kan fødes fra TIM.

11.3.3 Autenticitet(ITAR)

Skal tilvejebringes i Front End systemerne for at overholde det generelle princip om perimetersikring. I forbindelse med
processen konverteres brugerens akkreditiver til en unik bruger-ID der er anvendelig på tværs af enterprise arkitekturen.
Autenticitet sikres i interne systemer ved Windows Logon, der baseres på Active Directory
Ved ekstern portal adgang anvendes OCES certifikat og net-ID baseret login gennem IBM Tivoli Access Manager.
Alternativ Id : 1014
Kravtype : Funktionelt
Kravstiller : SIKA/ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1  Ansvarlig : SIKA/ITAR

Accept Kriterie :
Der redegøres for at løsningen anvender Windows sikkerhed ved login. Dette kan dels ske via Active Directory eller ved at der ved
browser baserede systemer tilbydes single sign on med SPNEGO.

11.3.4 Konfidentialitet(ITAR)

Sikres ved at kryptere data under transmission over åbne netværk. Dette skal foregå ved hjælp af protokoller og
algoritmer, der lever op til internationalt anerkendte krav om interoperabilitet og sikkerhed.

Alternativ Id : 1015
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Der er redegjort for at datatrafik mellem aktører er krypteret når følsomme data passerer over åbne net eller hvis
følsomme data midlertidigt parkeres på offentligt tilgængelige medier.

11.3.5 Uafviselighed(ITAR)

Dette sikres ved at alle forretningstransaktioner med parter udenfor ATP gennemføres med brug af
digital signatur. ATP's interne medarbejdere betragtes som betroede medarbejdere og er undtaget
regelen. Ved interne medarbejde skal der forefindes et kontrol- og transaktionsspor som viser hvilken
medarbejder der har udført en given handling.

Alternativ Id : 1016
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Løsningen redegør for understøttelse af digital signatur med net-ID og OCES ved forretningstransaktioner med eksterne




                                                                                                         1
                                                                                        15.12.2005


aktører. Ved løsninger der er rettet mod interne aktører er der redegjort for et fyldestgørende kontrol- og transaktionsspor.

11.3.6 Autorisation(ITAR)

Autorisationer tildeles efter den rolle baserede model. Autorisationen tildeles i applikationslaget (Front End) således at
brugerne kun får adgang til funktioner, som de er autoriserede til. Det forudsættes at de interne systemer er betroede og
via design ikke giver brugerne funktionalitet der ligger ud over design rammerne.
For backend komponenter kan autorisation tildeles på komponent- eller metode niveau. Det er best-practice at undlade
autorisations styring i backend komponenterne, men hvis særlige forhold kræver det skal det foregå efter ATP's generelle
rolle definitioner.
Som minimum skal backend systemerne være sikret med systemsikkerhed således at det kun er relevante front end
systemer der kan tilgå backend funktonaliteten.
Alternativ Id : 1017
Kravtype : Funktionelt
Kravstiller : SIKA/ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1  Ansvarlig : SIKA/ITAR

Accept Kriterie :
Der er redegjort for at backend funktioner (serviceinterfaces) er sikret med systemsikkerhed som eksempelvis
netværkssikkerhed eller tekniske bruger ID.
Der er redegjort for hvordan frontend funktioner er kategoriseret og forberedt for konfiguration af autorisation i henhold til
ATP's rollemodel og med anvendelse af ATP's sikkerhedskomponenter,

11.3.7 Formel autorisationsprocedure- og arbejdsgang(ITAR)

Der skal være fastlagt en formel autorisationsprocedure- og arbejdsgang. Heri skal indgå, at der forud for tildelingen af
autorisation til persondata foretages en vurdering af, hvad den enkelte bruger har behov for at være autoriseret til.
Vurderingen og godkendelsen heraf skal foretages på funktionsniveau og af den pågældendes funktionschef.

Alternativ Id : 1018
Kravtype : Funktionelt
Kravstiller : SIKA/ITAR den : 2005 09 16
Status : Nyt      Prioritet : 2  Ansvarlig : SIKA/ITAR

Accept Kriterie :
Løsningen indeholder de fornødne procedurebeskrivelser og vejledninger for tildeling af brugerrettigheder.

11.3.8 Begrænsning af brugernes adgange(ITAR)

Der er behov for at etablere tekniske løsninger, der begrænser brugernes adgang til de oplysninger, der er nødvendige.
Her nævnes bl.a. geografiske, tidsmæssige og opgavemæssige begrænsninger.

Alternativ Id : 1019
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 2   Ansvarlig : ITAR

Accept Kriterie :
Der er i løsningen redegjort for de parametre der er til rådighed for at reducere mængden af informationer som brugerne
får adgang til.




                                                                                                    1
                                                                                      15.12.2005



11.3.9 Stikprøvekontrol af systemloggen(ITAR)

Med interne kontrolordninger sigtes f.eks. til muligheden for, at foretage stikprøvevis kontrol af loggen i systemer med
følsomme oplysninger; dels af præventive hensyn, dels med henblik på at opdage og undersøge eventuelt misbrug af
adgang.


Alternativ Id : 1021
Kravtype : Funktionelt
Kravstiller : SIKA/ITAR den : 2005 09 16
Status : Nyt      Prioritet : 2  Ansvarlig : SIKA/ITAR

Accept Kriterie :
Verifikation af tilstedeværelse kontrolordninger


11.3.10             Supplerende kontroller(ITAR)

Mulighed for supplerende ordninger bør overvejes f.eks. en løsning, hvor det noteres i systemet, hvorfor der foretages
opslag. Formålet er at sikre, at der kun behandles oplysninger, når det er nødvendigt.

Alternativ Id : 1022
Kravtype : Funktionelt
Kravstiller : SIKA den : 2005 09 16
Status : Nyt      Prioritet : 2   Ansvarlig : SIKA




11.3.11             Krav til ekstern kommunikation(ITAR)

Der må kun etableres eksterne kommunikationsforbindelser, hvis der træffes særlige foranstaltninger for at sikre, at
uvedkommende ikke gennem disse forbindelser kan få adgang til oplysninger. Ligeledes skal der sikres mod virus og
hacker-angreb.
A. Der skal foretages beskrivelse af kommunikationsformer, teknisk udstyr og interessenter.
B. Der skal foretages sikkerhedsvurdering af alle elementer i kommunikationen.
C. Nye kommunikationsformer skal godkendes af SIKU.
D. Datatilsynets krav fremgår af særskilt bilag
Alternativ Id : 1023
Kravtype : Funktionelt
Kravstiller : SIKA/ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1  Ansvarlig : ITAR

Accept Kriterie :
Løsningen indeholder detaljeret beskrivelse af de elementer der er nævnt under pkt. A.
Verifikation af tilstedeværelse kontrolordninger

11.3.12             Selvbetjening via portal(ITAR)

Koncernkunderne skal i højere grad betjene sig selv via atp's portal.
Kravet er at:
 koncernkunder skal have adgang til udvalgte applikationer af to typer a) rapportering b) produktionsapparatet,
 sagsbehandlere også skal have adgang til applikationerne uanset om de er på kontor(ATP) eller arbejder hjemme




                                                                                                  1
                                                                                      15.12.2005


   der skal være differentieret adgang til data afhængig af om man er sagsbehandler eller leder.
Alternativ Id : 1024
Kravtype : Funktionelt
Kravstiller : BPR Referencedokument_190805_Uden supp slides.ppt den : 2005 09 29
Status : Nyt      Prioritet :   Ansvarlig : ITAR




11.3.13            Overholdelse af sikkerhedsstanderder og -lovgivning(ITAR)

Overholdelse af sikkerhedsstandarder og -lovgivning:

Systemet skal leve op til ATP's Informationssikkerhedspolitik, der er baseret på den internationale
    standard DS/ISO/IEC 17799 Informationsteknologi - Regelsæt for styring af
    informationssikkerhed. Kontrol af systemets overholdelse af ATP's Informationssikkerhedspolitik
    vil tage udgangspunkt i checklister baseret på DS/ISO/IEC 17799.

Systemet skal til enhver tid leve op til Persondatalovens krav til behandling af personoplysninger samt
    Justitsministeriets gældende sikkerhedsbekendtgørelse. Systemet skal ligeleds kunne leve op til
    Finanstilsynets gældende Vejledning om kontrol- og sikringsforanstaltninger på it-området.
Alternativ Id : 1025
Kravtype : Non-funktionelt
Kravstiller : SIKA den : 2005 10 05
Status : Nyt      Prioritet : 1   Ansvarlig : SIKA




11.4 Test(ITAR)



11.4.1 Test i hht ATP_s testdisciplin(ITAR)

For test af løsningen skal der udarbejdes en teststrategi med tilhørende testplaner. Eventuelle aftalte afvigelser fra ATP's
testdisciplin skal fremgå af teststrategien. Termer i ATP's testdisciplin skal anvendes.

Alternativ Id : 1026
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Tjek at der er udarbejdet en teststrategi med tilhørende testplaner.

11.4.2 Funktionel test(ITAR)

Leverandøren skal udføre dyb funktionel test af alle komponentoperationer. Leverandøren skal levere beskrivelse af de
procedurer, der er anvendt ved planlægning, gennemførelse og kvalitetssikring af testen.




                                                                                                  1
                                                                                                  15.12.2005


Alternativ Id : 1027
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Leverandøren skal fremvise testcases samt dokumentere at der er gennemført test med testcasene.

11.4.3 Grænsefladetest(ITAR)

Leverandøren skal udføre grænsefladetest mellem alle komponenter i løsningen, samt test af alle serviceoperationer.
Leverandøren skal levere beskrivelse af de procedurer, der er anvendt ved planlægning, gennemførelse og
kvalitetssikring af testen.

Alternativ Id : 1028
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
Leverandøren skal fremvise testcases samt dokumentere at der er gennemført test med testcasene.

11.4.4 ATPs testmanagementværktøj(ITAR)

Leverandøren skal anvende ATP's testmanagementværktøj i kommunikation om testcases og fejlrapportering.

Alternativ Id : 1029
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR




11.4.5 Leverancer(ITAR)

Leverandøren skal udarbejde leveranceplaner, der skal specificere forudsætninger (hardware, software, processer) for
installation i ATP' afviklingsmiljø. Enhver leverance skal omfatte den leverede løsning, en specifikation af løsningen,
installationsvejledning, testcases til verificering af korrekt installation på ATP's afviklingsmiljø samt hvilke fejlrapporter, der
er rettet og medtaget i leverancen.
Leverancebeskrivelsen skal desuden indeholde status for gennemført test og dokumentation for aftalt kvalitet.
Leverandøren skal være til rådighed under installation og installationstest.
Alternativ Id : 1030
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR

Accept Kriterie :
En leverance er først leveret, når den er installeret i ATP's afviklingsmiljø med den aftalte kvalitet og den aftalte funktionalitet, og uden
blokerende fejl.

11.4.6 Fejlhåndtering(ITAR)




                                                                                                                1
                                                                                    15.12.2005


Leverandøren skal følge ATP's fejlhåndteringsproces, som fremgår af retningslinierne i ATP's testdisciplin. Af denne
fremgår bl.a. hvad og hvordan der kommunikeres om fejl (fejltyper, prioritering, vigtighed m.v.).

Alternativ Id : 1031
Kravtype : Funktionelt
Kravstiller : ITAR den : 2005 09 16
Status : Nyt      Prioritet : 1   Ansvarlig : ITAR




                                                                                                1
                                 15.12.2005




12 M IT-PRODUKTION(PRPL, PRTK)




                                         1
                                                                                                                                                                        15.12.2005


   Out of Scope(PRPL/PRTK)                                                                             Configuration management, konfigurationsstyring(PRPL/PRTK)

               O1 Systemet kommer ikke ud af              O9 Sandsynlighedskontroller i                         CFG1 Al dokumentation skal leveres i           CFG12 Navngivning må ikke være
               synkronisme(PRPL/PRTK)                     systemet(PRPL/PRTK)                                   elektronisk(PRPL/PRTK)                         begrænsende(PRPL/PRTK)

               O2 Systemerne skal være                    O10 Håndtering af redundante                          CFG2 Ingen indtastning af variable ifbm        CFG13 Reorganisering mens systemet
               selvafstemmende(PRPL/PRTK)                 data(PRPL/PRTK)                                       job- og procesafvikling(PRPL/PRTK)             er online(PRPL/PRTK)

               O3 Håndtering af tunge                     O11 Tilbagekaldelsesrutiner på                        CFG3 Tegning over                              CFG14 Oplysninger om tidsafhængige
               brugerstartede kørsler(PRPL/PRTK)          elektroniske overførsler(PRPL/PRTK)                   systemet(PRPL/PRTK)                            hændelser(PRPL/PRTK)

               O4 Datering af breve(PRPL/PRTK)            O12 Ikke samme dataleverance flere                    CFG4 Dataflow for miljø(PRPL/PRTK)             CFG15 Sameksistens af batch- og
                                                          gange(PRPL/PRTK)                                                                                     online(PRPL/PRTK)

               O5 Online vedligeholdelse af               O13 Indlæsning af periodiske                          CFG5 Driftsdokumentation for                   CFG16 Processer skal kunne afvikles
               centrale tabeller m.v.(PRPL/PRTK)          leverancer i rækkefølge(PRPL/PRTK)                    miljø(PRPL/PRTK)                               når somhelst(PRPL/PRTK)

               O6 Information til Internet                O14 Leverandørens                                     CFG6 Installationsvejledning(PRPL/PRTK)        CFG17 Distribution af klient-softw are via
               brugere(PRPL/PRTK)                         referencer(PRPL/PRTK)                                                                                TNG SDO(PRPL/PRTK)

               O7 Håndtering af logiske                   O15 Stop dataudveksling mellem                        CFG7                                           CFG18 Elektronisk behandling af output
               fejl(PRPL/PRTK)                            grænseflader(PRPL/PRTK)                               Konfigurationsparamneter(PRPL/PRTK)            til brugere(PRPL/PRTK)

               O8 Afstemning mellem programmer            O16 Undgå specifik                                                                                   CFG19 Leverandørens hardw are
                                                                                                                CFG8 Håndtering af alarmer og
               og grænsefalder(PRPL/PRTK)                 udsendelsesdato(PRPL/PRTK)                                                                           krav(PRPL/PRTK)
                                                                                                                handlinger(PRPL/PRTK)
                                                                                                                                                               CFG20 Leverandørens softw are
                                                                                                                CFG9 Beskrivelse af
                                                                                                                                                               krav(PRPL/PRTK)
                                                                                                                batch-job(PRPL/PRTK)
   Generelt(PRPL/PRTK)
                                                                                                                                                               CFG21 Det infrastrukturmæssige
                                                                                                                CFG10 Identifikation af
                                                                                                                                                               vedligehold(PRPL/PRTK)
          G1 Placering af databaser i et              G7 Online vedligeholdelse af centrale                     jobnavn(PRPL/PRTK)
          databasehotel(PRPL/PRTK)                    tabeller m.v.(PRPL/PRTK)
                                                                                                                CFG11 Navngivning skal være                    CFG22 Håndtering af fejl(PRPL/PRTK)
          G2 Databaser skal være                      G8 Procedure for performancetest og                       unik(PRPL/PRTK)
          platformuafhængige(PRPL/PRTK)               regressionstest(PRPL/PRTK)

          G3 Understøttelse af virtuelplatform        G9 Performancetest som fast element
                                                                                                       Business management, forretningsoverblik(PRPL/PRTK)
          baseret på WM-w are(PRPL/PRTK)              i alle testfaser(PRPL/PRTK)

          G4 Adskillelse af data og                   G10 Samarbejdsgrænseflade mellem                          BM1 Levering af logisk tegning over            BM4 Læseadgang til
          applikation(PRPL/PRTK)                      leverandør og ATP(PRPL/PRTK)                              miljø(PRPL/PRTK)                               syslog/eventlog(PRPL/PRTK)

          G5 Adskillelse af produktions- og           G11 Væsentlige succesfaktorer for                         BM2 Levering af legning over                   BM5 Systemet er designet til 24 timers
          test/udviklingsmiljø(PRPL/PRTK)             leverance(PRPL/PRTK)                                      systemlandskabet(PRPL/PRTK)                    drift(PRPL/PRTK)

          G6 Leverandøren har udelukkende                                                                       BM3 Systemet kan indpasses i ATP               BM6 Versions- og
          adgang til testmiljø(PRPL/PRTK)                                                                       miljø(PRPL/PRTK)                               releasepolitik(PRPL/PRTK)




  Change management, vedligeholdelsesstyring(PRPL/PRTK)                                                     Operation management, driftsstyring(PRPL/PRTK)


         CHMG1 Understøttelse af test-, pilot- og     CHMG7 Overførsel af job-/ proces-                             OM1 Business view til                                 OM18 Backup/restore(PRPL/PRTK)
         produktionsmiljøer(PRPL/PRTK)                defintioner fra test til produktion(PRPL/PRTK)                overvågningsmiljøet(PRPL/PRTK)

         CHMG2 Gennemførelse af ændringer             CHMG8 Ændring til databaser(PRPL/PRTK)                        OM2 Overvågning pr                                    OM19 Lukke brugere ud af systemet, mens
         efter aftale(PRPL/PRTK)                                                                                    forretningsapplikation(PRPL/PRTK)                     det er kørende(PRPL/PRTK)

         CHMG3 Gennemførelse af ændringer i           CHMG9 Leverancebeskrivelse(PRPL/PRTK)                         OM3 Nuanceret overvågning(PRPL/PRTK)                  OM20 Overvågning på tekniske
         pakker(PRPL/PRTK)                                                                                                                                                delkomponenter(PRPL/PRTK)

         CHMG4 Flytning mellem testmiljøer og         CHMG10 Databaserettelser som                                  OM4 Automatisk inaktivering af fejlende               OM21 Batch-komponenter skifter
         pilot-/produktionsmiljøer(PRPL/PRTK)         DMLér(PRPL/PRTK)                                              komponenter (PRPL/PRTK)                               døgn(PRPL/PRTK)

         CHMG5 Leverandør i dialog med                CHMG11 Oplysningsfrist for                                    OM5 Leverandørens anbefaling(PRPL/PRTK)               OM22 Driftsdøgn afviger fra
         ATP(PRPL/PRTK)                               opgraderinger(PRPL/PRTK)                                                                                            systemdøgn(PRPL/PRTK)

         CHMG6 Lukning af systemet ifbm               CHMG12 Oplysningsfrist for almindelig                         OM6 Dokumentation af severity for
                                                                                                                                                                          OM23 Ingen tidsmæssige afhændigheder i
         vedligehold(PRPL/PRTK)                       vedligehold(PRPL/PRTK)                                        hændelser(PRPL/PRTK)
                                                                                                                                                                          systemet(PRPL/PRTK)

                                                                                                                    OM7 Logning af hændelser(PRPL/PRTK)                   OM24 Initiering af
Capacity management, kapacitetsstyring(PRPL/PRTK)                                                                                                                         processer/jobs(PRPL/PRTK)

                                                                                                                    OM8 System integereres til Tivoli                     OM25 Returkoder til
      CAP1 Estimering af                                                                                            overvågning(PRPL/PRTK)                                leverandøren(PRPL/PRTK)
      kapacitetstrækket(PRPL/PRTK)
                                                                                                                    OM9 Recovery håndterer automatisk                     OM26 Automatiseret jobafvikling(PRPL/PRTK)
      CAP2 Beregningsmodel for                                                                                      data-recovery(PRPL/PRTK)
      kapacitetstrækketPRPL/PRTK)
                                                                                                                    OM10 Online backupt(PRPL/PRTK)                        OM27 Log alle former for
      CAP3 Forventet
                                                                                                                                                                          kommunikation(PRPL/PRTK)
      kapacitetsudvikling(PRPL/PRTK)
                                                                                                                    OM11 Checkpoint/restart(PRPL/PRTK)                    OM28 Batch-komponenter genererer
      CAP4 Procedure for performancetest og
                                                                                                                                                                          kørselslog(PRPL/PRTK)
      regressionstest(PRPL/PRTK)
                                                                                                                    OM12 Automatisk roll-back foretages af                OM29 Sytemloggens indhold(PRPL/PRTK)
      CAP5 Performancetest som fast element i
                                                                                                                    transaktioner(PRPL/PRTK)
      testfaser(PRPL/PRTK)
                                                                                                                    OM13 Afviklingstid for                                OM30 Særlig alarm ved fejl i online
Accounting, forbrugsstyring(PRPL/PRTK)                                                                              batch-komponenter(PRPL/PRTK)                          opdateringer(PRPL/PRTK)

                                                                                                                    OM14 Afvikling af årskørsler og                       OM31 Automatisk lukning af
      AC1 Accounting på systemet(PRPL/PRTK)
                                                                                                                    adhoc-kørsler(PRPL/PRTK)                              delsystemer(PRPL/PRTK)

      AC2 Forretningsområders forbrug af                                                                            OM15 Total system recovery(PRPL/PRTK)                 OM32 Saneringsprogrammer(PRPL/PRTK)
      ressourcer(PRPL/PRTK)

      AC3 Overførsel af opfølgningsdata til                                                                         OM16 Recovery af en mindre del af                     OM33 Stop dataudveksling mellem
      ERP-system(PRPL/PRTK)                                                                                         systemet(PRPL/PRTK)                                   grænseflader(PRPL/PRTK)

      AC4 Registrering af forbrug(PRPL/PRTK)                                                                       OM17 Afvikling af backup efter                         OM34 Hindring af igangsættelse af
                                                                                                                   frekvenser(PRPL/PRTK)                                  produktionskritiske kørsler(PRPL/PRTK)

      AC5 Opfølgning på systemets oppe- og
      svartider(PRPL/PRTK)


 Problem management, problemhåndtering(PRPL/PRTK)

     PM1 Online adgang til
     problemmanagement(PRPL/PRTK)

     PM2 Leverandørens
     supportorganisation(PRPL/PRTK)


Document management, dokumenthåndtering(PRPL/PRTK)

         DOC1 Elektronisk arkivering af ind- og
         udgående dokumenter(PRPL/PRTK)

         DOC2 Central håndtering af layoustandarder
         m.v.(PRPL/PRTK)

         DOC3 Udvikling af meget komplekse
         meddelelser(PRPL/PRTK)

         DOC4 Effektiv støtte til
         enkeltmeddelelser(PRPL/PRTK)

         DOC5 Enkelt at tilrette tekster(PRPL/PRTK)


         DOC6 Enkelt at tilrette tekster til
         enkeltmeddelelser(PRPL/PRTK)

         DOC7 Billig af udføre opgaver(PRPL/PRTK)                                                                                                                                                           1
                                                                                        15.12.2005



                                                Figure 12 M IT-PRODUKTION(PRPL, PRTK)




12.1 Capacity management, kapacitetsstyring(PRPL/PRTK)



12.1.1 CAP1 Estimering af kapacitetstrækket(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal estimere kapacitetstrækket i miljøet.
Alternativ Id : 1100
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.1.2 CAP2 Beregningsmodel for kapacitetstrækketPRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal angive beregningsmodellen for kapacitetstrækket
Alternativ Id : 1101
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.1.3 CAP3 Forventet kapacitetsudvikling(PRPL/PRTK)

Domæner/projekter: Alle.
Forventet kapacitetsudvikling skal beskrives.
Alternativ Id : 1102
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.1.4 CAP4 Procedure for performancetest og regressionstest(PRPL/PRTK)

Domæner/projekter: Test.
Løsningen skal leveres med procedure for performancetest og regressionstest.
Alternativ Id : 1103
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11




                                                                                                1
                                                                                     15.12.2005


Status : Nyt      Prioritet :     Ansvarlig : PRPL/PRTK




12.1.5 CAP5 Performancetest som fast element i testfaser(PRPL/PRTK)

Domæner/projekter: Test.
Performancetest skal være element i alle testfaser før pilot/produktionsmiljøet.
Alternativ Id : 1104
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.2 Accounting, forbrugsstyring(PRPL/PRTK)



12.2.1 AC1 Accounting på systemet(PRPL/PRTK)

Domæner/projekter: Itar/teknik.
Der skal kunne foretages accounting på systemet.
Alternativ Id : 1105
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.2.2 AC2 Forretningsområders forbrug af ressourcer(PRPL/PRTK)

Domæner/projekter: Itar/teknik.
De enkelte forretningsområders forbrug af ressourcer skal elektronisk registreres.
Alternativ Id : 1106
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.2.3 AC3 Overførsel af opfølgningsdata til ERP-system(PRPL/PRTK)

Domæner/projekter: Itar/teknik.
Resultatet af opfølgning skal elektronisk kunne overføres til ATP's ERP-system.
Alternativ Id : 1107
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                             1
                                                                                    15.12.2005




12.2.4 AC4 Registrering af forbrug(PRPL/PRTK)

Domæner/projekter: Itar/teknik.
Følgende elementer skal der registreres forbrug på:
    Forbrug af processorkapacitet.
    Forbrug af diskkapacitet
    Printforbrug
Alternativ Id : 1108
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.2.5 AC5 Opfølgning på systemets oppe- og svartider(PRPL/PRTK)

Domæner/projekter: Itar/teknik.
Det skal være muligt at følge op på systemets oppe- og svartider. Leverandøren skal beskrive, hvordan det er muligt.
Alternativ Id : 1109
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.3 Problem management, problemhåndtering(PRPL/PRTK)



12.3.1 PM1 Online adgang til problemmanagement(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal stille online adgang til problemmanagement system til rådighed.
Alternativ Id : 1110
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.3.2 PM2 Leverandørens supportorganisation(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal beskrive hvordan og hvilken supportorganisation der stille til rådighed for ATP.
Alternativ Id : 1111
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                                1
                                                                                           15.12.2005




12.4 Document management, dokumenthåndtering(PRPL/PRTK)



12.4.1 DOC1 Elektronisk arkivering af ind- og udgående dokumenter(PRPL/PRTK)

Domæner/projekter: DokH.
Alle ind- og udgående dokumenter uanset kanal og medie arkiveres som elektroniske dokumenter i dokumentarkivet.
Arkiveringen skal være yderst robust og driftsikker herunder med en tolerance over for defekte omgivende systemer.
Alternativ Id : 1112
Status : Prioritet :       Ansvarlig :




12.4.2 DOC2 Central håndtering af layoustandarder m.v.(PRPL/PRTK)

Domæner/projekter: DokH.
Der skal understøttes en centralt håndtering af layoutstandarder, skabeloner, fraser og formuleringer, som bredt ligger til
grund for generering af indhold, herunder til masseforsendelser, enkelt meddelelser og fx portal information. Informationen
kan være mere eller mindre individualiseret, og med formatering o.a. tilpasning til de endelige medier og kanaler.

Det skal være enkelt at få overblik og vedligeholde content, herunder med gode oversigter over de indgående dele,
varianter, variabler, mv. Der skal være understøttelse af sub-branding, formularer mv.
Alternativ Id : 1113
Status : Prioritet :       Ansvarlig :




12.4.3 DOC3 Udvikling af meget komplekse meddelelser(PRPL/PRTK)

Domæner/projekter: DokH.
Man skal kunne lave meget komplekse, dybt individualiserede meddelelser, fx et pensionsbevis til et medlem med en
dækningsoversigt, der overskueligt redegør for netop hans valgte, samlede dækning med relevante forhold belyst, med en
depotoversigt og eventuelt med en prognose. Forsikringssystemet forventes her at give alle størrelser og data, der kan
ligge til grund for sammensætningen af tekster og udfyldelsen af de forskellige variable.
Sådanne meddelelser skal kunne dannes i store volumener fx til alle medlemmer ved en årsudsendelse.

Kravet til funktionalitet og stabilitet er højt - det årlige pensionsbevis er en kritisk og højtprofileret informationsaktion over
for medlemmet
Alternativ Id : 1114
Status : Prioritet :       Ansvarlig :




12.4.4 DOC4 Effektiv støtte til enkeltmeddelelser(PRPL/PRTK)

Domæner/projekter: DokH.
Endvidere skal der være effektiv støtte til enkeltmeddelelser (det der i dag fx er sagsbreve), hvor meddelelsen til




                                                                                                        1
                                                                                       15.12.2005


sagsbehandleren kombineres af faste elementer givet ud fra konteksten, men også med mulighed for fritekst. I alle
anvendelser - også de simplere - skal der kunne substitueres med systemudfyldte tekstvariable.

Visse meddelelser skal kunne være i mange sprog, hvilket skal understøttes i fuld bredde.
Alternativ Id : 1115
Status : Prioritet :       Ansvarlig :




12.4.5 DOC5 Enkelt at tilrette tekster(PRPL/PRTK)

Domæner/projekter: DokH.
Det skal være enkelt ikke alene at tilrette tekster, men også at ajourføre det udtræksprogrammel der føder dannelsen af
en meddelelse - der skal være en løs kobling mellem indgående data og brugen af disse data i produktionen af
meddelelsen.
Alternativ Id : 1116
Status : Prioritet :       Ansvarlig :




12.4.6 DOC6 Enkelt at tilrette tekster til enkeltmeddelelser(PRPL/PRTK)

Domæner/projekter: DokH.
Tilsvarende skal det være enkelt at tilrette tekster til enkeltmeddelelser (det der i dag fx er sagsbreve) og at definere nye
tekster og meddelelser
Alternativ Id : 1117
Status : Prioritet :       Ansvarlig :




12.4.7 DOC7 Billig af udføre opgaver(PRPL/PRTK)

Domæner/projekter: DokH.
Almindeligt forekommende opgaver skal være billige, kunne udføres af almene ressourcer / superbrugere og afsluttes
hurtigt, fx skal brevrettelser som standard gennemføres teknisk på nogle få timer.
Alternativ Id : 1118
Status : Prioritet :       Ansvarlig :




12.5 Out of Scope(PRPL/PRTK)



12.5.1 O1 Systemet kommer ikke ud af synkronisme(PRPL/PRTK)

Leverandøren skal beskrive, hvordan det sikres at systemet ikke kommer ud af synkronisme med den
øvrige del af ATP's systemlandskab.




                                                                                                    1
                                                                                   15.12.2005


Alternativ Id : 1119
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.2 O2 Systemerne skal være selvafstemmende(PRPL/PRTK)

Systemerne skal være selvafstemmende. Hvis recovery ikke har fundet sted, som det forventes, skal
afstemningerne give udslag.

Alternativ Id : 1120
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig :




12.5.3 O3 Håndtering af tunge brugerstartede kørsler(PRPL/PRTK)

Det skal overvejes hvordan tunge brugerstartede kørsler skal håndteres i miljøet - må brugerne have mulighed for det.

Alternativ Id : 1120
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.4 O4 Datering af breve(PRPL/PRTK)

Datering af breve og øvrige formularer skal være automatiskstyret.

Alternativ Id : 1121
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.5 O5 Online vedligeholdelse af centrale tabeller m.v.(PRPL/PRTK)

Systemadministrator skal online kunne vedligeholde indholdet i centrale tabeller, hjælperegistre og øvrige generelle
parametre. Vedligeholdelsen skal tilrettelægges, således at den kan foretages af brugere uden specielle edb-kundskaber.

Alternativ Id : 1122
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                               1
                                                                                       15.12.2005




12.5.6 O6 Information til Internet brugere(PRPL/PRTK)

Ved internet applikationer, skal der informeres til brugere på internettet at systemet ikke er tilgængeligt, samt oplysning
om hvornår systemet igen forventes at være tilgængeligt.

Alternativ Id : 1123
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.7 O7 Håndtering af logiske fejl(PRPL/PRTK)

Logiske fejl (fx. afstemningsfejl) rettes via engangsprogrammer. Dvs. der fortages ikke tilbagestilling.

Alternativ Id : 1124
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.8 O8 Afstemning mellem programmer og grænsefalder(PRPL/PRTK)

Systemet skal være selvafstemmende ligesom der skal være automatisk afstemmelighed på data fra program til program,
og fra/til eksterne leverandører.

Systemets grænseflader til omgivelserne skal være forsynet med passende kontroltællere, således at ATP kan afstemme
overførsler med tilsvarende optællinger på den modsatte side af grænsefladen.
Alternativ Id : 1125
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.9 O9 Sandsynlighedskontroller i systemet(PRPL/PRTK)

Der skal indlægges sandsynlighedskontroller i systemet, som er med til at sikre mod fejl i forbindelse med indbetalinger,
udbetaling, brevudsender og elektroniske overførsler.

Alternativ Id : 1126
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                                   1
                                                                                    15.12.2005




12.5.10          O10 Håndtering af redundante data(PRPL/PRTK)

Leverandøren skal sikre at der ikke modtages og udveksles redundante data.

Alternativ Id : 1127
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.11          O11 Tilbagekaldelsesrutiner på elektroniske overførsler(PRPL/PRTK)

På alle elektroniske overførsler skal der være indarbejdet tilbagekaldsrutiner .

Alternativ Id : 1128
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.12          O12 Ikke samme dataleverance flere gange(PRPL/PRTK)

Leverandøren skal sikre, at samme dataleverance ikke kan indlæses i systemet flere gange.

Alternativ Id : 1129
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.13          O13 Indlæsning af periodiske leverancer i rækkefølge(PRPL/PRTK)

Leverandøren skal sikre, at data fra periodiske leverancer indlæses i den sekvens, hvori disse er udtrukket.

Alternativ Id : 1130
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.14          O14 Leverandørens referencer(PRPL/PRTK)

Leverandøren skal angive referencer. Primært ønskes danske finansielle referencer.




                                                                                                 1
                                                                                    15.12.2005




Alternativ Id : 1131
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.15           O15 Stop dataudveksling mellem grænseflader(PRPL/PRTK)

Det skal være muligt at stoppe dataudveksling mellem grænseflader fra centralt hold i relation til eksempelvis 1. gangs
produktion.

Alternativ Id : 1132
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.5.16           O16 Undgå specifik udsendelsesdato(PRPL/PRTK)

Undgå specifik udsendelsesdato på større printmængder som ikke har juridiske konsekvenser, og angiv i stedet måned
for udsendelse, af hensyn til større fleksibilitet ved masseudsendelser.

Alternativ Id : 1133
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.6 Generelt(PRPL/PRTK)



12.6.1 G1 Placering af databaser i et databasehotel(PRPL/PRTK)

Domæner/projekter: Teknik
Databaser skal være designet så de kan placeres i et databasehotel (UDB og SQL).
Alternativ Id : 1134
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :     Ansvarlig : PRPL/PRTK




12.6.2 G2 Databaser skal være platformuafhængige(PRPL/PRTK)

Domæner/projekter: Teknik




                                                                                                1
                                                                                     15.12.2005


Databaser skal være platformsuafhængige, således at der er flytbarhed mellem ATP's startegiskeplatforme- Z/OS, AIX og
Windows.
Alternativ Id : 1135
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.6.3 G3 Understøttelse af virtuelplatform baseret på WM-ware(PRPL/PRTK)

Domæner/projekter: Teknik
Applikationer udviklet til Microsoftserverplatform skal understøtte afvikling på virtuelplatform baseret på WM-ware.
Alternativ Id : 1136
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.6.4 G4 Adskillelse af data og applikation(PRPL/PRTK)

Domæner/projekter: Alle.
Applikation og data skal være adskilt.
Alternativ Id : 1137
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.6.5 G5 Adskillelse af produktions- og test/udviklingsmiljø(PRPL/PRTK)

Domæner/projekter: Alle.
Det skal være muligt at adskillele mellem produktions- og test/udviklingsmiljø.
Alternativ Id : 1138
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.6.6 G6 Leverandøren har udelukkende adgang til testmiljø(PRPL/PRTK)

Domæner/projekter: Teknik.
Leverandøren har udelukkende adgang til test-miljø jf. skitse over driftsmiljø.
Alternativ Id : 1139
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                                  1
                                                                                  15.12.2005



12.6.7 G7 Online vedligeholdelse af centrale tabeller m.v.(PRPL/PRTK)

Domæner/projekter: Alle.
Systemadministrator skal online kunne vedligeholde indholdet i centrale tabeller, hjælperegistre og øvrige generelle
parametre. Vedligeholdelsen skal tilrettelægges, således at den kan foretages af brugere uden specielle edb-kundskaber.
Alternativ Id : 1140
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.6.8 G8 Procedure for performancetest og regressionstest(PRPL/PRTK)

Domæner/projekter: Test.
Leverandøren skal levere procedure for performancetest og regressionstest.
Alternativ Id : 1141
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.6.9 G9 Performancetest som fast element i alle testfaser(PRPL/PRTK)

Domæner/projekter: Test.
Performancetest skal være element i alle testfaser inkl. pilotmiljøet.
Alternativ Id : 1142
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.6.10           G10 Samarbejdsgrænseflade mellem leverandør og ATP(PRPL/PRTK)

Domæner/projekter: Teknik.
Leverandøren skal beskrive deres forslag til samarbejdsgrænseflade mellem Leverandøren og ATP
Alternativ Id : 1143
Kravtype : Funktionelt
Status : Prioritet :       Ansvarlig :




12.6.11           G11 Væsentlige succesfaktorer for leverance(PRPL/PRTK)

Domæner/projekter: Teknik.
Leverandøren skal beskrive de væsentligste succesfaktorer for leverancen.
Alternativ Id : 1144
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11




                                                                                              1
                                                                                             15.12.2005


Status : Nyt     Prioritet :      Ansvarlig : PRPL/PRTK




12.7 Change management, vedligeholdelsesstyring(PRPL/PRTK)



12.7.1 CHMG1 Understøttelse af test-, pilot- og produktionsmiljøer(PRPL/PRTK)

Domæner/projekter: Teknik.
Systemet skal understøtte test, pilot og produktionsmiljøer , jf. skitse over driftsmiljø.
Alternativ Id : 1145
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.2 CHMG2 Gennemførelse af ændringer efter aftale(PRPL/PRTK)

Domæner/projekter: Alle.
Ændringer gennemføres efter aftalte releaseplan.
Alternativ Id : 1146
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.3 CHMG3 Gennemførelse af ændringer i pakker(PRPL/PRTK)

Domæner/projekter: Alle.
Ændringer skal gennemføres i pakker så der her igennem kan sikres sammenhæng mellem miljøerne.
Alternativ Id : 1147
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.4 CHMG4 Flytning mellem testmiljøer og pilot-/produktionsmiljøer(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal beskrive flytningen mellem testmiljøer og pilot-/produktionsmiljø.
Alternativ Id : 1148
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                                     1
                                                                                 15.12.2005




12.7.5 CHMG5 Leverandør i dialog med ATP(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal indgå i dialog med ATP om change management procedurerne for systemet.
Alternativ Id : 1149
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.6 CHMG6 Lukning af systemet ifbm vedligehold(PRPL/PRTK)

Domæner/projekter: Teknik
I forbindelse med change og øvrig systemvedligeholdelse skal systemer kunne lukkes.
Alternativ Id : 1150
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.7 CHMG7 Overførsel af job-/ proces- defintioner fra test til produktion(PRPL/PRTK)

Domæner/projekter: Teknik
Job/processdefinitioner skal kunne overføres fra test-systemer til produktion.
Alternativ Id : 1151
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.8 CHMG8 Ændring til databaser(PRPL/PRTK)

Domæner/projekter: Teknik
Ændringer til databasen skal leveres automatiseret.
Alternativ Id : 1152
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.9 CHMG9 Leverancebeskrivelse(PRPL/PRTK)

Domæner/projekter: Alle.
Ved hver leverance skal der følge en leverancebeskrivelse.
Alternativ Id : 1153




                                                                                           1
                                                                                  15.12.2005


Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt     Prioritet :    Ansvarlig : PRPL/PRTK




12.7.10           CHMG10 Databaserettelser som DMLér(PRPL/PRTK)

Domæner/projekter: Alle.
Databaserettelser skal leveres som DML'er.
Alternativ Id : 1154
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.11           CHMG11 Oplysningsfrist for opgraderinger(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal senest 3 måneder inden en opgraderinger oplyse hvilke andre softwareprodukter, som er berørt af
opgraderingen, og om disse kræver opgradering af paths og andre konfigurationsvariable.
Alternativ Id : 1155
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.7.12           CHMG12 Oplysningsfrist for almindelig vedligehold(PRPL/PRTK)

Domæner/projekter: Alle
Almindelig vedligehold skal meddeles ATP 2 dage inden iværksættelse, og afleveres til ATP senest kl. 10.00 på
iværksættelsesdagen.
Alternativ Id : 1156
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8 Configuration management, konfigurationsstyring(PRPL/PRTK)



12.8.1 CFG1 Al dokumentation skal leveres i elektronisk(PRPL/PRTK)

Domæner/projekter: Alle.
Al dokumentation skal leveres elektronisk.
Alternativ Id : 1157
Kravtype : Non-funktionelt




                                                                                              1
                                                                                     15.12.2005


Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt     Prioritet :    Ansvarlig : PRPL/PRTK




12.8.2 CFG2 Ingen indtastning af variable ifbm job- og procesafvikling(PRPL/PRTK)

Domæner/projekter: Alle.
Systemet skal designes, således at der ikke skal indtastes variable (f.eks. dato) i forbindelse med job- og processafvikling
af systemet.
Alternativ Id : 1158
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.3 CFG3 Tegning over systemet(PRPL/PRTK)

Domæner/projekter: Alle.
Der skal leveres en tegning over systemet der som minimum angiver:
    Systemsammenhænge
    Grænseflader (eksterne og interne)
    Øvrige involverede systemer
    Der skal indgå en ”black-box” tegning som angiver input og output fra systemet
Alternativ Id : 1159
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.4 CFG4 Dataflow for miljø(PRPL/PRTK)

Domæner/projekter: Alle.
Der skal leveres dataflow for miljøet, både for processor og batch.
Alternativ Id : 1160
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.5 CFG5 Driftsdokumentation for miljø(PRPL/PRTK)

Domæner/projekter: Alle.
Driftsdokumentation for miljøet skal som minimum indeholde:
     Kort beskrivelse af formålet med systemet
     Change Management oplysninger
     Programnavn
     Stationær parametre




                                                                                                  1
                                                                                    15.12.2005


     Servernavn/tcp ip adr
     Navn på sti (stinavn + navn på fil)
     Navn på logfil (kørselsstatistik)
     Print oplysninger
     Printernavn
     Blanket numre
     Docdef
     Printfile nr/navn
     Print estimat
     Retention cycles (levetid på filer)
     Kørselsfrekvens pr. afviklingsserver
     Berørte online delsystemer
     Grænseflader / afhængigheder til andre systemer
     Interne og eksterne brugere
     Fallback-håndtering
      Afviklingsserver
      Linieforbindelser
      Graduering af fejltyper
Alternativ Id : 1161
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Accepteret        Prioritet :   Ansvarlig : PRPL/PRTK




12.8.6 CFG6 Installationsvejledning(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal levere installationsvejledning, som beskriver installationsproceduren for systemet som det kører i
ATP's miljø.
Alternativ Id : 1162
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.7 CFG7 Konfigurationsparamneter(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal angive de opsatte konfigurationsparametre for systemet.
Alternativ Id : 1163
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.8 CFG8 Håndtering af alarmer og handlinger(PRPL/PRTK)

Domæner/projekter: Alle.
Alarmer og handlinger på disse skal beskrives.




                                                                                                1
                                                                                 15.12.2005


Alternativ Id : 1164
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.9 CFG9 Beskrivelse af batch-job(PRPL/PRTK)

Domæner/projekter: Alle.
Alle batch-job skal være beskrevne. Beskrivelsen skal som minimum indeholde:
     Formål, institution og opgave som jobbet understøtter
     Jobnavn
     Opsætning af job
     Afviklingstid
     Kapacitetstræk - CPU, disk, memory
     Forventet input/output
     Fejlhåndtering
     Understøttelse af checkpoint/restart
     Yderligere forhold omkring jobbet.
Alternativ Id : 1165
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.10           CFG10 Identifikation af jobnavn(PRPL/PRTK)

Domæner/projekter: Alle.
Systemet skal nemt kunne identificeres på navn på job, databaser og processor.
Alternativ Id : 1166
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.11           CFG11 Navngivning skal være unik(PRPL/PRTK)

Domæner/projekter: Alle.
Navngivning skal være unik indenfor hver enkel komponent i systemet.
Alternativ Id : 1167
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.12           CFG12 Navngivning må ikke være begrænsende(PRPL/PRTK)

Domæner/projekter: Alle.




                                                                                         1
                                                                                 15.12.2005


Navngivning må ikke være begrænsende i forhold til opgradering og vedligehold.
Alternativ Id : 1168
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.13           CFG13 Reorganisering mens systemet er online(PRPL/PRTK)

Domæner/projekter: Teknik.
Eventuel reorganisering skal kunne foretages mens systemet er online.
Alternativ Id : 1169
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.14           CFG14 Oplysninger om tidsafhængige hændelser(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal oplyse om tidsafhængige hændelser i systemet.
Alternativ Id : 1170
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.15           CFG15 Sameksistens af batch- og online(PRPL/PRTK)

Domæner/projekter: Alle.
Batch og online skal kunne sameksistere - dvs. begge skal kunne afvikles sideløbende uden indflydelse på performance.
Alternativ Id : 1171
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.16           CFG16 Processer skal kunne afvikles når somhelst(PRPL/PRTK)

Domæner/projekter: Alle.
Processer skal kunne afvikles på et hvilket som helst tidspunkt af døgnet.
Alternativ Id : 1172
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                             1
                                                                                   15.12.2005



12.8.17           CFG17 Distribution af klient-software via TNG SDO(PRPL/PRTK)

Domæner/projekter: Teknik
Klientbaseret software skal distribueres via TNG SDO. Det foretrækkes at pakken leveres i MSI-format.
Alternativ Id : 1173
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.18           CFG18 Elektronisk behandling af output til brugere(PRPL/PRTK)

Domæner/projekter: Teknik.
Output til brugere skal behandles elektronisk og opbevares i Content Manager.
Alternativ Id : 1174
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.19           CFG19 Leverandørens hardware krav(PRPL/PRTK)

Domæner/projekter: Teknik
Leverandøren skal angive hardware krav til systemet.
Alternativ Id : 1175
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.20           CFG20 Leverandørens software krav(PRPL/PRTK)

Domæner/projekter: Teknik
Leverandøren skal angive software krav til systemet.
Alternativ Id : 1176
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.8.21           CFG21 Det infrastrukturmæssige vedligehold(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal angive det infrastrukturmæssige vedligehold, som er nødvendigt i forhold til systemet.
Alternativ Id : 1177
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                               1
                                                                                       15.12.2005




12.8.22           CFG22 Håndtering af fejl(PRPL/PRTK)

Domæner/projekter: Alle.
Ved fejl i forbindelse med job/processer, skal leverandøren leverer et rettelse modul. ATP foretages ikke tilbagestilling/roll-
back.
Alternativ Id : 1178
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.9 Business management, forretningsoverblik(PRPL/PRTK)



12.9.1 BM1 Levering af logisk tegning over miljø(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal levere en logisk tegning over miljøet inkl. infrastrukturen.
Alternativ Id : 1179
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.9.2 BM2 Levering af legning over systemlandskabet(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal levere en tegning over systemlandskabet. Inklusiv en beskrivelse af baggrunden for designet.
Alternativ Id : 1180
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.9.3 BM3 Systemet kan indpasses i ATP miljø(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal sikre at systemet kan indpasses i ATP miljø jf. skitse over driftsmiljø.
Alternativ Id : 1181
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                                    1
                                                                                15.12.2005




12.9.4 BM4 Læseadgang til syslog/eventlog(PRPL/PRTK)

Domæner/projekter: Alle.
ATP skal have læseadgang til syslog/eventlog.
Alternativ Id : 1182
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.9.5 BM5 Systemet er designet til 24 timers drift(PRPL/PRTK)

Domæner/projekter: Alle.
Systemet skal være designet til 24 timers drift alle årets dage.
Alternativ Id : 1183
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.9.6 BM6 Versions- og releasepolitik(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal beskrive versions- og releasepolitik.
Alternativ Id : 1184
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10 Operation management, driftsstyring(PRPL/PRTK)



12.10.1           OM1 Business view til overvågningsmiljøet(PRPL/PRTK)

Domæner/projekter: Teknik
Leverandøren skal leverer mulighed for Business view til overvågningsmiljøet.
Alternativ Id : 1185
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                        1
                                                                                  15.12.2005



12.10.2           OM2 Overvågning pr forretningsapplikation(PRPL/PRTK)

Domæner/projekter: Teknik
Der skal være samlet overvågning pr. forretningsapplikation.
Alternativ Id : 1186
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.3           OM3 Nuanceret overvågning(PRPL/PRTK)

Domæner/projekter: Teknik
Overvågningen skal være så nuanceret at overvågningsfunktionen kan se hvilken del komponent som fejler.
Alternativ Id : 1187
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.4           OM4 Automatisk inaktivering af fejlende komponenter (PRPL/PRTK)

Domæner/projekter: Teknik
Fejlende komponenter skal inaktiveres automatisk, efterfølgende alarm til overvågningen.
Alternativ Id : 1188
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.5           OM5 Leverandørens anbefaling(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal anbefale hvilke dele af systemet, som bør overvåges.
Alternativ Id : 1189
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.6           OM6 Dokumentation af severity for hændelser(PRPL/PRTK)

Domæner/projekter: Alle.
Severity for hændelser skal dokumenteres, så det fremgår hvordan hændelsen skal håndteres.
Alternativ Id : 1190
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                             1
                                                                                      15.12.2005




12.10.7           OM7 Logning af hændelser(PRPL/PRTK)

Domæner/projekter: Alle.
Systemet skal foretage logning af hændelse i processerne.
Alternativ Id : 1191
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.8           OM8 System integereres til Tivoli overvågning(PRPL/PRTK)

Domæner/projekter: Teknik
Systemet skal integrerer til Tivoli overvågning, alternativt levere SNMP traps til overvågning.
Alternativ Id : 1192
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.9           OM9 Recovery håndterer automatisk data-recovery(PRPL/PRTK)

Domæner/projekter: Teknik
Recovery skal håndtere automatisk data-recovery i tilfælde af nedbrud uden tab af ajourførte data og accepterede
transaktioner.
Alternativ Id : 1193
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.10          OM10 Online backupt(PRPL/PRTK)

Domæner/projekter: Teknik
Der skal være muligt at tage backup online, uden at systemet lukkes - hverken batch eller online.
Alternativ Id : 1194
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.11          OM11 Checkpoint/restart(PRPL/PRTK)

Domæner/projekter: Alle.




                                                                                                  1
                                                                                      15.12.2005


Checkpoint/restart funktionalitet skal være implementeret i batchmiljøet.
Alternativ Id : 1195
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.12          OM12 Automatisk roll-back foretages af transaktioner(PRPL/PRTK)

Domæner/projekter: Alle.
Transaktioner skal automatisk kunne foretage roll-back - ingen ”halve” transaktioner.
Alternativ Id : 1196
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.13          OM13 Afviklingstid for batch-komponenter(PRPL/PRTK)

Domæner/projekter: Alle.
Den samlede afviklingstiden for batch-komponenter må ikke overstige 2 timer i periodiske kørsler (daglige, ugentlige,
månedlige kørsler).
Alternativ Id : 1197
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.14          OM14 Afvikling af årskørsler og adhoc-kørsler(PRPL/PRTK)

Domæner/projekter: Alle.
Ved årskørsler og adhoc-kørsler, hvor det ikke er muligt at holde den samlede afviklingstid inden for 2 timer, skal der
foreligge en plan for programforløbet, så afviklingen kan gennemføres kontrolleret og evt. overvåget.
Alternativ Id : 1198
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.15          OM15 Total system recovery(PRPL/PRTK)

Domæner/projekter: Teknik
Total system recovery må maksimalt udgøre 4 timer.
Alternativ Id : 1199
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                                  1
                                                                                     15.12.2005




12.10.16         OM16 Recovery af en mindre del af systemet(PRPL/PRTK)

Domæner/projekter: Teknik
Recovery af en mindre del af systemet skal tidsmæssigt stå i rimeligt forhold til total system recovery. Leverandøren skal
beskrive dette forhold.
Alternativ Id : 1200
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.17         OM17 Afvikling af backup efter frekvenser(PRPL/PRTK)

Domæner/projekter: Teknik
Der skal kunne afvikles backup efter frekvenser som variabelt kan ændres.
Alternativ Id : 1201
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.18         OM18 Backup/restore(PRPL/PRTK)

Domæner/projekter: Teknik
Backup skal tages så der i en fejlsituation foretages restore på såvel hele databaser som enkelte tabel.
Alternativ Id : 1202
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.19         OM19 Lukke brugere ud af systemet, mens det er kørende(PRPL/PRTK)

Domæner/projekter: Teknik
Brugere skal simpelt kunne lukkes ude af systemet, mens det er kørende.
Alternativ Id : 1203
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.20         OM20 Overvågning på tekniske delkomponenter(PRPL/PRTK)

Domæner/projekter: Teknik
Der skal tilbydes overvågning på tekniske delkomponenter, så som MQ og fysiske linier.




                                                                                                 1
                                                                                 15.12.2005


Alternativ Id : 1204
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.21          OM21 Batch-komponenter skifter døgn(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal beskrive hvornår en batch-komponent skifter døgn.
Alternativ Id : 1205
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.22          OM22 Driftsdøgn afviger fra systemdøgn(PRPL/PRTK)

Domæner/projekter: Alle.
Hvis et driftsdøgn afviger fra et systemdøgn skal dette beskrives.
Alternativ Id : 1206
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.23          OM23 Ingen tidsmæssige afhændigheder i systemet(PRPL/PRTK)

Domæner/projekter: Alle.
Systemet skal designes, så der ikke er tidsmæssige afhængigheder i systemet.
Alternativ Id : 1207
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.24          OM24 Initiering af processer/jobs(PRPL/PRTK)

Domæner/projekter: Teknik.
Processer/jobs skal initieres og styres af ATP's scheduleringsværktøj, Tivoli.
Alternativ Id : 1208
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                         1
                                                                                    15.12.2005



12.10.25          OM25 Returkoder til leverandøren(PRPL/PRTK)

Domæner/projekter: Alle.
Leverandøren skal benytte følgende returkoder: 0, 4, 8, 12, 16.
Hvor 0 er fejlfri gennemførsel, og 16 er den mest kritiske fejl type som kan forekomme.
Alternativ Id : 1209
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.26          OM26 Automatiseret jobafvikling(PRPL/PRTK)

Domæner/projekter: Alle.
Al job afvikling skal være automatiseret.
Alternativ Id : 1210
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.27          OM27 Log alle former for kommunikation(PRPL/PRTK)

Domæner/projekter: Alle.
Alle former for kommunikation skal logges i Eventloggen.
Alternativ Id : 1211
Kravtype : Funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.28          OM28 Batch-komponenter genererer kørselslog(PRPL/PRTK)

Domæner/projekter: Alle.
Batch-komponenter skal altid generere en kørselslog, som beskriver kørselsforløbet og returkoder.
Alternativ Id : 1212
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.29          OM29 Sytemloggens indhold(PRPL/PRTK)

Domæner/projekter: Alle.
Systemloggen skal indeholde:
    Timestamp (process start og sluttid)
    Returkoder




                                                                                              1
                                                                                     15.12.2005


     Process navn og versionsnummer
     Fejlmeddelelser: Hvis batch-komponenten fejler, bør dette fremgå tydeligt af loggen, så genkørsel eller
      korrektionskørsler kan gennemføres.
Alternativ Id : 1213
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.30          OM30 Særlig alarm ved fejl i online opdateringer(PRPL/PRTK)

Domæner/projekter: Alle.
Der kræves særlig alarm, hvis fejlen betyder at online-opdatering ikke kan foregå korrekt.
Alternativ Id : 1214
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.31          OM31 Automatisk lukning af delsystemer(PRPL/PRTK)

Domæner/projekter: Teknik.
Der skal automatisk lukkes for delsystemer med fejl.
Alternativ Id : 1215
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.32          OM32 Saneringsprogrammer(PRPL/PRTK)

Domæner/projekter: Alle.
Der skal leveres saneringsprogrammer inkl. beskrives af disse inkl. angivelse af kørselsfrekvens.
Alternativ Id : 1216
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




12.10.33          OM33 Stop dataudveksling mellem grænseflader(PRPL/PRTK)

Domæner/projekter: Teknik.
Det skal være muligt at stoppe dataudveksling mellem grænseflader fra centralt hold i relation til eksempelvis 1. gangs
produktion.
Alternativ Id : 1217
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                                1
                                                                        15.12.2005




12.10.34          OM34 Hindring af igangsættelse af produktionskritiske kørsler(PRPL/PRTK)

Domæner/projekter: Alle.
Løsningen skal designes så brugere kan hindres i at igangsætte.
Alternativ Id : 1218
Kravtype : Non-funktionelt
Kravstiller : PRPL/PRTK den : 2005 10 11
Status : Nyt      Prioritet :   Ansvarlig : PRPL/PRTK




                                                                                 1

								
To top