03... · Web viewVersion gemt efter Word gik ned. XMHK. 0.9. 06.07.2012. Kaj J. kommentarer...

Bilag 3Leverancebeskrivelse med Kravspecifikation og Løsningsbeskrivelse Patent- og VaremærkestyrelsenOprettet dato: 27. april 2012Af: Marianne Helledi Knudsen

Versioner:

Version nr.

Dato Ændringer Ændret af

0.0 27.04.2012

Oprettet på basis af ”Funktionelle krav v. 0.1.3”

XMHK

0.1 02.05.2012

Ikke-funktionelle krav tilføjet.Underbilag klippet ud og lagt i separat filTilføjet og redigeret FESD2’s kapitel 3

XMHK

0.2 03.05.2012

Indledende kapitler tilføjet XMHK

0.2.1 03.05.12 Version gemt efter word gik ned XMHK

0.2.2 03.05.12 Afsnit 2 og 3 tilrettet på baggrund af kommentarer fra JSG

TJ

0.3 08.05.12 Første udkast af hele kravspecifikationen oprettet.Sendt til review hos test manager

XMHK

0.4 10.05.12 Kommentarer og rettelser tilføjet efter review af TestManager

XST

0.5 15.05.12 Input fra test manager inkluderet i dokument XMHK

0.6 30.05.12 Input fra løsningsarkitekter indføjet i dokument og sendt til procesejere, JSG og test manager til review

XMHK

Side 1 af 198

0.7 18.06.12 Input fra procesejere, ANDU og test manager inkorporeret

XMHK

0.8 19.06.12 JSG kommentarer inkorporeret.Version gemt efter Word gik ned

XMHK

0.9 06.07.2012

Kaj J. kommentarer inkorporeretInfo-krav opdateret med PVS-IDBemærkninger vurderet og forældede bem. er slettet, mens aktuelle bem. er inkorporeret i tekst. Visse bem. er bevaret for historikkens skyld.Ikke-droppede krav på teamsite holdt op mod krav her.

XMHK

0.10 09.07.2012

Kravtyper vurderet og opdelt i Krav, Mindstekrav og Optioner.

TJ

0.11 04.09.2012

Henvisninger opdateret. Bemærkninger enten implementeret eller slettet.

TJ

1.0 12.09.2012

Endelige rettelser inkl. rettelser på baggrund af input fra Silverbullet

TJ

Side 2 af 198

Indholdsfortegnelse1. Indledning..........................................................................................................................7

1.1 Dette dokument.........................................................................................................71.2 Afklaringsfase.............................................................................................................71.3 Ordliste.......................................................................................................................81.4 Struktur og læsevejledning......................................................................................101.5 Krav og usecases.....................................................................................................11

2. Overordnede mål.............................................................................................................122.1 Løsningen og dens omgivelser.................................................................................122.2 Forretningsmæssige mål..........................................................................................132.3 Succeskriterier.........................................................................................................14

3. Vejledning til Leverandøren ved kravbesvarelse..............................................................153.1 Krav..........................................................................................................................153.2 Kravopfyldelsesliste..................................................................................................153.3 Løsningsbeskrivelse.................................................................................................16

4. Lovgivning og standarder.................................................................................................174.1 Lovgivning................................................................................................................174.2 Offentlighedsloven og forvaltningsloven..................................................................174.3 Arkivloven................................................................................................................194.4 Lov om behandling af personoplysninger.................................................................194.5 Digitale dokumenters bevisværdi.............................................................................214.6 Fælles offentlig standardisering...............................................................................22

5. Aktører.............................................................................................................................236. Forretningsobjekter Løsningen skal anvende...................................................................24

6.1 Arkiv – forretningsobjekt..........................................................................................246.2 Sag – forretningsobjekt............................................................................................276.3 Dokument – forretningsobjekt..................................................................................326.4 Interessent – forretningsobjekt.................................................................................396.5 Opgaveklassifikation - forretningsobjekt..................................................................446.6 Organisation - forretningsobjekt...............................................................................47

7. Arbejdsopgaver Løsningen skal understøtte....................................................................507.1 Delarbejdsgange......................................................................................................50

Side 3 af 198

7.1.1 Opretter sag – delarbejdsgang..............................................................................507.1.2 Behandler sag – delarbejdsgang...........................................................................517.1.3 Afslutter sag – delarbejdsgang..............................................................................557.1.4 Tilknytter Interessent – delarbejdsgang................................................................557.1.5 Modtager og placerer post – delarbejdsgang........................................................587.1.6 Danner og afsender post – delarbejdsgang...........................................................667.1.7 Opretter og behandler dokument - delarbejdsgang..............................................717.1.8 Udveksler sager og dokumenter - delarbejdsgang................................................737.1.9 Afleverer til offentligt arkiv – delarbejdsgang........................................................747.1.10 Danner sagsprocesoverblik – delarbejdsgang....................................................777.1.11 Hent information til sagsbehandling - delarbejdsgang......................................797.1.12 Ekstern høring – delarbejdsgang.......................................................................817.1.13 Behandler aktindsigt – delarbejdsgang..............................................................83

7.2 Centrale behovstemaer og funktionaliteter..............................................................837.2.1 Brugervenlighed...................................................................................................847.2.2 Automatisering.....................................................................................................897.2.3 Søgning og fremfinding.........................................................................................907.2.4 Samlemapper........................................................................................................957.2.5 Systemadministration...........................................................................................987.2.6 Workflow funktionalitet.......................................................................................102

7.3 Øvrige behovstemaer og funktionelle krav.............................................................1067.3.1 Skanning og OCR................................................................................................1067.3.2 Dagsorden- og udvalgsbehandling......................................................................1117.3.3 Forelæggelse......................................................................................................1127.3.4 Journalarksmodul................................................................................................1177.3.5 Visning og overblik..............................................................................................1227.3.6 Rapporter og statistikker....................................................................................127

8. Ikke-funktionelle krav.....................................................................................................1298.1 Arkitektur og miljøer...............................................................................................1298.2 Datamodel..............................................................................................................1308.3 Konvertering af data...............................................................................................1318.4 Standarder.............................................................................................................132

Side 4 af 198

8.5 Struktur, forandringsparathed og platform.............................................................1338.6 Integration..............................................................................................................136

8.6.1 Integration generelt............................................................................................1378.6.2 Import af klassesystemer....................................................................................1388.6.3 Import af MP varemærkedata fra WIPO...............................................................1398.6.4 Eksport af MP varemærkedata til WIPO...............................................................1408.6.5 Import af IR varemærkedata fra WIPO................................................................1408.6.6 Eksport af prioritetsbeviser til WIPO....................................................................1418.6.7 Eksport af danske patent- og brugsmodeldata til EPO........................................1418.6.8 Eksport af bortfaldsliste til EPO...........................................................................1428.6.9 Import af EP patentdata fra EPO.........................................................................1428.6.10 Import af EU varemærkedata fra OHIM...........................................................1438.6.11 Eksport af varemærkedata til TMView.............................................................1448.6.12 Import fra E-ansøgning....................................................................................1448.6.13 Import fra EOLF...............................................................................................1458.6.14 Eksport til CRM................................................................................................1468.6.15 Integration til økonomisystem.........................................................................1468.6.16 Eksport til PVSonline........................................................................................1478.6.17 Integrationsmønstre, kommunikationsstandarder, integritet, sikkerhed og pålidelighed...................................................................................................................147

8.7 Sikkerhed og brugerstyring....................................................................................1518.8 Brugbarhed og tilgængelighed...............................................................................1578.9 Åbenhed og dokumentation...................................................................................159

9. Løsningsbeskrivelse.......................................................................................................1629.1 Lovgivning og standarder.......................................................................................1629.2 Forretningsobjekter Løsningen skal understøtte.....................................................162

9.2.1 Arkiv...................................................................................................................1629.2.2 Sag.....................................................................................................................1629.2.3 Dokument - forretningsobjekt.............................................................................1629.2.4 Interessent – forretningsobjekt...........................................................................1639.2.5 Opgaveklassifikation - forretningsobjekt.............................................................163

9.3 Arbejdsopgaver Løsningen skal understøtte...........................................................163

Side 5 af 198

9.3.1 Delarbejdsgange.................................................................................................1639.3.2 Centrale behovstemaer og funktionaliteter.........................................................1659.3.3 Øvrige behovstemaer og funktionaliteter...........................................................167

9.4 Ikke-funktionelle krav.............................................................................................1679.4.1 Arkitektur og miljøer...........................................................................................1689.4.2 Datamodel..........................................................................................................1689.4.3 Struktur, forandringsparathed og platform.........................................................168

9.5 Integration..............................................................................................................1689.5.1 Integration generelt............................................................................................1689.5.2 Eksport til CRM....................................................................................................1689.5.3 Integration til økonomisystem............................................................................1699.5.4 Integration – integrationsmønstre, kommunikationsstandarder, integritet, sikkerhed og pålidelighed..............................................................................................169

9.6 Sikkerhed og brugerstyring....................................................................................1699.7 Brugbarhed og tilgængelighed...............................................................................1699.8 Åbenhed og dokumentation...................................................................................169

Side 6 af 198

1. Indledning

1.1 Dette dokumentDette dokument beskriver Patent- og Varemærkestyrelsens (herefter Kunden) krav til et ESDH system med integreret workflow modul, som skal implementeres i løbet af 2013. Kunden lægger op til en anskaffelse af et standardsystem, der understøtter de offentlige standarder gældende på området, og som kan implementeres med mindst mulige specialtilpasninger. Kunden har taget udgangspunkt i Den fælles offentlige kravspecifikation FESD II [1]. Beskrivelsen af kravene er på et overordnet niveau og har til formål at give Leverandøren et tilstrækkeligt grundlag til at kunne vurdere i hvor høj grad det tilbudte system kan honorere kravene i standard konfiguration, og i hvor høj grad der er nødvendigt med specialudvikling. Kunden forventer dermed, at selve detaildesignet bliver fastlagt i samarbejde med Leverandøren under en kort afklaringsfase efter kontraktindgåelsen (se afsnit 1.2). Henvisningen nedenfor kan bruges af Leverandøren til evt. at uddybe forståelsen for baggrunden til krav fremsat i nærværende dokument.

Nummer Dokument

[1] Den fælles offentlige kravspecifikation, version 0.2. maj 2009. http://modernisering.dk/fileadmin/user_upload/documents/Projekter/FESD/Den_faelles_offentlige_kravspecifikation_version_0.2.pdf

1.2 AfklaringsfaseMed henblik på at sikre, at Leverandøren har samtlige nødvendige specifikke informationer om udvikling, drift og vedligeholdelse, vil der blive gennemført en teknisk afklaringsfase hos Kunden, hvor kravspecifikation med tilhørende løsningsbeskrivelse (bilag 3) samt øvrige relevante ydelser gennemgås og vurderes, for at se om der eventuelt er behov for at præcisere eller supplere kravspecifikationen og løsningsbeskrivelsen samt de øvrige bilags indhold. Afklaringsfasen gennemføres af Leverandøren i samarbejde med Kunden, der stiller de hos Kunden nødvendige ressourcer til rådighed.Formålet med afklaringsfasen er ikke at udvide eller ændre i kravspecifikationen, men alene at afklare uklarheder der måtte være i denne, og håndtere eventuelle forbehold, Leverandøren har taget i løsningsbeskrivelsen. Forhold, som klart fremgår af det skriftlige materiale, som Leverandøren har fået stillet til rådighed inden afklaringsfasen gennemføres, skal således som udgangspunkt ikke indgå i afklaringsfasen, bortset fra i relation til Leverandørens eventuelle mulighed for at verificere de angivne oplysninger. Det forventes ikke, at Leverandøren i afklaringsfasen verificerer faktuelle oplysninger, men alene afdækker de områder, hvor oplysningsmaterialet giver anledning til tvivl enten som følge af, at Kunden selv har gjort opmærksom på dette, eller hvor Leverandøren grundet sit generelle kendskab til forholdene

Side 7 af 198

http://modernisering.dk/fileadmin/user_upload/documents/Projekter/FESD/Den_faelles_offentlige_kravspecifikation_version_0.2.pdf

http://modernisering.dk/fileadmin/user_upload/documents/Projekter/FESD/Den_faelles_offentlige_kravspecifikation_version_0.2.pdf

omkring udvikling, installation, drift og vedligehold af en leverance som den af kontrakten omfattede, er opmærksom på uklarheder ved materialet. Endvidere kan afklaringsfasen afdække behov, som ikke er tilstrækkeligt beskrevet i det eksisterende kontraktgrundlag. Aktiviteter i afklaringsfasen fremgår af Bilag 1.

1.3 OrdlisteOrd/begreb Forklaring

Ankenævnet Ankenævnet for Patenter og Varemærker. Kunden og Ankenævnet har indgået et administrativt servicefællesskab.

Brugsmodel Brugsmodellen kaldes også for "det lille patent". Der er ”lavere” krav til at få en opfindelse beskyttet som brugsmodel end ved et patent. Brugsmodelbeskyttelsen kan maksimalt gælde i 10 år.

CPC CPC (Cooperative Patent Classification) er et klassesystem fælles mellem Europa og USA, som skal bruges til klassificering af alle patenter og brugsmodeller. CPC træder i kraft 1. januar 2013. (www.cpcinfo.org)

CRM Customer Relationship Management system.

CTM CTM står for Community Trademark og er et varemærke, der gælder for hele EU. CTM administreres af EU's kontor for varemærker og design, OHIM.

Design Design bruges her som synonym for en designrettighed. En designrettighed kan opnås for udseendet af et produkt og designregistreringen gælder i op til 25 år.

EOLF EOLF (Epoline Online Filing) er et system til elektronisk indlevering af patentansøgninger. Systemet bruges både til indlevering af europæiske ansøgninger, men også til indlevering af danske nationale patentansøgninger til Kunden. EOLF er integreret med Epoline.

EPO European Patent Office er det Europæiske Patentkontor, hvor man kan ansøge om at få et patent, der er gyldigt i de af den Europæiske Patentkonventions medlemslande, hvor patentet valideres (www.epo.org).

EP patenter EP patenter (DK/EP) er patenter, som er ansøgt gennem og udstedt af EPO, og valideret i Danmark.

Epoline Epoline er en samling webprogrammer og tjenester, der gør det muligt bl.a. at indlevere patentansøgninger online til EPO

Side 8 af 198

Ord/begreb Forklaring

Erhvervsservice Kommercielle tjenesteydelser, som ydes af Kunden. Behandlingen af sager inden for erhvervsservice adskiller sig fra sagsbehandling på rettigheder. (Se Rettighed)

LLøsningen Den konkrete løsning, der indeholder alle de forretningstjenester applikationer, komponenter og interfaces samt den nødvendige funktionalitet og brugergrænseflader, der skal til for at it-understøtte sagsbehandlingen hos Kunden

Gefion Gefion er Kundens navn for ESDH-systemet Acadre fra Traen og er Kundens emnesagssystem. Heri håndteres alle sager og dokumenter, der ikke er direkte relateret til rettighedssager eller erhvervsservicesager.

Interessent Interessenter er parter i sager samt andre individer eller organisationer, der er tilknyttet sager. Det kan være fuldmægtige for ansøgere, erhvervsservicekunder eller andre korrespondanceparter. For Kunden er det vigtigt, at det er ordet ”interessent” der bliver brugt i forbindelse med navngivning i database mv. såvel som i brugergrænsefladen

IR varemærker Internationalt registrerede varemærker er varemærker, der har opnået gyldighed i Danmark via en MP-protokol-ansøgning til OHIM (EU's varemærke- og designkontor).

Madrid-protokollen Madrid-protokollen er et internationalt system, hvor man på basis af én varemærkeansøgning, kan få registreret sit varemærke i flere lande. Ordningen administreres af WIPO. Varemærker udstedt efter Madrid-protokollen kaldes MP mærker.

MECA Madrid Electronic CommunicAtions. MECA er en standard for informationsudveksling fastlagt af WIPO, som tager sigte på udveksling af meddelelser vedrørende varemærker udstedt efter Madrid-protokollen.

MP mærker MP mærker er varemærker udstedt efter Madrid-protokollen.

NPI Nordic Patent Institute. Kunden og NPI har indgået et administrativt servicefællesskab på mange områder.

OHIM Office for Harmonization in the Internal Market. EU-myndighed, der er ansvarlig for registrering af varemærker og design, som er gyldige i alle EU's medlemslande. (www.oami.europa.eu)

Side 9 af 198

http://www.oami.europa.eu/


Patent Et patent er en ret til at forbyde andre at udnytte en opfindelse kommercielt. For at kvalificere til et patent skal opfindelsen være ny, have opfindelseshøjde og kunne udnyttes industrielt. Et patent kan gælde i op til 20 år.

Part Part er et individ eller en organisation, der berøres væsentligt af afgørelsen af en sag. En part er også interessent.

PVS Patent- og Varemærkestyrelsen

PVSonline PVSonline er Kundens webbaserede database med offentligt tilgængelige ansøgninger og rettigheder samt tilhørende dokumenter.

QA procedurer QA procedurer er de procedurer for sagsbehandlingen, som er beskrevet i Kundens kvalitetsstyringssystem.

Rettighed Rettighed omfatter i denne sammenhæng de typer af rettigheder, som Patent- og Varemærkestyrelsen har hjemmel til at udstede på baggrund af ansøgninger. Det gælder patenter, brugsmodeller, varemærker, design, supplerende beskyttelsescertifikater (SPC) og pædiatrisk forlængelse af SPC.

TMView TMView er en fælles-europæisk varemærke portal, der giver mulighed for søgning i de tilmeldte landes varemærke ansøgninger og rettigheder. TMView administreres af OHIM (EU's varemærke- og designkontor).

uPDate Kundens nuværende sagsbehandlingssystem. Systemet er baseret på Worksafe og udviklet af Rambøll.

Validering Validering bruges i to betydninger, afhængig af konteksten:1. Om en handling, der sætter et EP patent i kraft i Danmark.

Der skal indleveres materiale samt betales et gebyr for at validere.

2. Om en systemhandling, der kontrollerer at data er gyldig.

Varemærke Et varemærke er det særlige navn eller kendetegn, som en virksomhed bruger til at markedsføre sig selv eller sine produkter og services. Et varemærke kan eksempelvis bestå af ord eller et logo, en kombination af de to elementer eller måske af en meget specielt udformet emballage. Der er ingen begrænsning på varigheden af varemærker, som skal fornys hvert tiende år.

WIPO World Intellectual Property Organization (www.wipo.int)

Side 10 af 198

http://www.wipo.int/


WIPO’s Digital Access Service (DAS)

WIPO’s Digital Access Service er et elektronisk bibliotek for prioritetsdokumenter. Når patentansøgere ønsker at videreføre patenter i andre lande, kan andre patentmyndigheder hente prioritetsbeviset direkte i WIPOs DAS uden at ansøger behøver at sende papirkopier.

1.4 Struktur og læsevejledningI dette afsnit beskrives detaljeret, hvordan kravspecifikationen skal læses, og hvordan Leverandøren sikrer sig overblik.

Afsnit 1 indeholder en introduktion og en ordliste, samt nærværende læsevejledning med beskrivelse af kravspecifikationens opbygning.Afsnit 2 beskriver baggrund, visioner og mål for Løsningen og et overblik over Kundens forventninger til arkitekturen for Løsningen og dens omgivelser. Afsnittet oplister desuden succeskriterierne for Løsningen. Afsnit 3 giver vejledning til Leverandørens kravbesvarelse.Afsnit 4 sætter rammer for og stiller krav i forhold til lovgivning, begreber og anvendelse af standarder.Afsnit 5 indeholder krav vedrørende de person- og systemaktører, som har interaktion med Løsningen.Afsnit 6 indeholder krav, der vedrører de forretningsobjekter, Løsningen skal anvende. Afsnit 7 indeholder krav relateret til de arbejdsopgaver, Løsningen skal understøtte, herunder

Delarbejdsgange Centrale behovstemaer og funktionaliteter Øvrige behovstemaer og funktionelle krav

Afsnit 8 indeholder alle ikke-funktionelle krav. De ikke-funktionelle krav er dels generelle retningsliner for arkitekturen, dels konkrete krav til de funktionelle løsningers tekniske egenskaber opdelt i grupperne

Arkitektur og miljø Datamodel Migrering af data Standarder Struktur, forandringsparathed, platform

Side 11 af 198

Integration Sikkerhed og brugerstyring Brugbarhed og tilgængelighed Åbenhed og dokumentation

Afsnit 9 indeholder Leverandørens løsningsbeskrivelse.

1.5 Krav og usecasesDe enkelte delarbejdsgange er kravspecificeret enten udelukkende med usecases, udelukkende med krav eller med en kombination af begge.De beskrevne usecases er en væsentlig del af kravspecifikationen, da de beskriver centrale dele af arbejdsgangene, både set fra aktørernes og systemets synsvinkel. Nogle usecases benytter andre usecases. I de situationer vil der i selve usecasen være henvisning til den pågældende usecase.Usecases skal ikke læses som ”den eneste måde” at udføre opgaverne på. Det centrale element er, at Leverandøren løser opgaven på den mest effektive og brugervenlige måde for brugeren. Kravene er formuleret på behovsniveau, der beskriver anvendelsesbehov fremfor konkrete løsninger. Det er op til Leverandøren at anvise den konkrete løsning, der bedst muligt dækker behovene.

Side 12 af 198

2. Overordnede målDette afsnit beskriver Kundens mål og succeskriterier for Kundens projekt vedrørende implementering af et nyt ESDH-system med integreret workflow modul. Afsnittet er alene tænkt som en oplysning til Leverandøren om, hvad der forretningsmæssigt er vigtigt for Kunden, og hvorledes den tilbudte løsning bidrager til indfrielsen af Kundens mål.Grundet et sammenfald af flere faktorer - blandt andet manglende fleksibilitet i den grundlæggende systemarkitektur, systemteknologisk forældelse, begrænsede udviklingsressourcer og begrænset kompatibilitet imellem systemer – har Kunden behov for, at få opdateret sit ESDH- og produktionsstyringssystem. Den forretningsmæssige vision er at opnå en ”one portal” brugeroplevelse, hvor brugerne har adgang til alle nødvendige funktioner og informationer gennem ét samlet system, der via en rollebaseret identificering af brugerne, understøtter alle Kundens processer digitalt.Systemet skal således, på en enkel og fleksibel måde, stille alle relevante data, dokumenter og funktioner - på tværs af andre databaser, systemer og ressourcer - til rådighed for brugeren på det rigtige tidspunkt i sagsbehandlingen på en sådan måde, at dette foregår transparent for brugeren. Systemet skal endvidere facilitere en automatiseret understøttelse af Kundens processer, herunder håndtering af henvendelser fra borgere og andre myndigheder samt behandling af rettigheds- og erhvervsservicesager. Endelig skal systemet facilitere en dynamisk og intuitiv tværgående søgefunktionalitet.

Den overordnede projektvision formuleres således:

”At implementere ét samlet, rollebaseret system til journalisering samt dokument- og sagsbehandling, herunder en indbygget tværgående søgefunktionalitet!”

Den tekniske vision er, at basere systemet på et standard ESDH-system med integreret workflow modul i en løst koblet arkitektur - baseret på Service Oriented Architecture (SOA) tankegangen - med åbne Application Programming Interfaces (API) og et standardiseret modul til data eksport/import via en integreret Extract, Transform, Load (ETL) proces. Herudover er det vigtigt, at systemet har en høj tilgængelighed og en brugervenlig grænseflade der sikrer, at brugerne oplever systemet som nemt at gå til og anvende.

2.1 Løsningen og dens omgivelser

Side 13 af 198

Nedenstående kontekstdiagram illustrerer Kundens forventning til Løsningen og dens omgivelser.

2.2 Forretningsmæssige målKunden forventer, at Løsningen bidrager til opnåelse af det anførte overordnede mål. Dette indebærer - men er ikke begrænset til – en understøttelse af blandt andet:

Systemet og alle tilknyttede services kan tilgås via single sign on og interaktion med services udenfor selve systemet er transparent for brugeren.

Brugergrænsefladen og den tilgængelige funktionalitet skal være rollebaseret og tilpasse sig brugeren og det aktuelle stadie i sagsbehandlingen.

Alle informationer og dokumenter vedrørende alle sager, skal lagres samme sted og data genbruges, således at de samme data kun skal indtastes én gang undervejs i sagsbehandlingen.

Alle eksisterende relevante data fra Kundens nuværende systemer uPDate og Gefion, skal være tilgængelige i det nye system for således at tage højde for, at rettigheder kan opretholdes i mange år og i enkelte tilfælde uendeligt.

Side 14 af 198

Systemet skal indeholde tværgående søgefunktionalitet, der gør det muligt at fremfinde dokumenter og sager på en let og effektiv måde, således at det er transparent for brugeren, hvilken service/system/database der leverer informationerne.

Kunden oplever et stadigt stigende internationalt samarbejde på især IT-området. Det er derfor vigtigt, at systemet har åbne API’er, der gør det muligt at integrere med andre systemer og udveksle data med udenlandske myndigheder.

2.3 Succeskriterier De forretningsmæssige mål er operationaliseret i forhold til en række succeskriterier, som skal indfries, for at Løsningen umiddelbart kan kaldes en succes.

Succeskriterierne er følgende:1. Løsningen skal understøtte, at medarbejderne arbejder digitalt, og give medarbejderne

mulighed for at udføre deres arbejde med udgangspunkt i ESDH-systemet med integreret workflow modul og i MS Office 2010 eller senere versioner.

2. Løsningen skal kunne integrere til andre it-systemer. Ved ibrugtagning er der oprettet integrationer til de it-systemer, der skal levere eller modtage data fra Løsningen.

3. Løsningen skal være mindre omkostningstungt end summen af omkostningerne til de eksisterende to systemer (Gefion og uPDate).

4. Løsningen lever op til offentlige standarder på ESDH-området (som angivet i FESD2-kravspecifikationen).

5. Den samlede Løsning er testet, overtaget og klar til brug senest ved udgangen af 2013.

Side 15 af 198

3. Vejledning til Leverandøren ved kravbesvarelse

3.1 KravBehovene er klassificeret som følger:

Mindstekrav Krav Option

Mindstekrav er ufravigelige krav, der skal opfyldes, hvis Leverandøren skal komme i betragtning.Krav beskriver de forretningsmæssige behov og skal som udgangspunkt opfyldes af Leverandøren og vil fremstå som konkurrenceparameter i tilbudssammenligningen, men Leverandøren kan dog tage forbehold.Option er et behov, der forventes et særskilt tilbud på, såfremt det ikke indgår som en del af Leverandørens standardløsning.Hvert krav er således angivet med: krav ID som løbende nummerering kravtype, som er:

- MK – Mindstekrav.- K – Krav. - O – Option.

kravtitlen med fed skrift

uddybende kravbeskrivelse – med fed skrift, hvis mindstekrav reference til underbilag eller lignende. FESD2 ref. angiver det krav (angivet som et tal) eller info (angivet som ”info.” og et tal) i

FESD2, som Kundens krav bygger på. * betyder at der alene er blevet foretaget redaktionelle ændringer i forhold til FESD2-kravet. ** betyder, at der er blevet foretaget indholdsmæssige ændringer i forhold til FESD2-kravet. Ingen stjerne betyder, at kravet er uændret i forhold til det angivne FESD2-krav. Dog er ”ESDH-løsningen” alle steder ændret til ”Løsningen”.

PVS ID angiver det unikke løbenummer i Kundens interne kravdatabase.

3.2 Kravopfyldelsesliste

Side 16 af 198

Leverandøren skal udfylde en kravopfyldelsesliste, som findes i Underbilag 3.1 til nærværende bilag, med angivelse af opfyldelsesgraden. Den udfyldte liste skal vedlægges som underbilag til nærværende bilag. Kravopfyldelseslisten har til formål at konstatere, hvorvidt opfyldelsen af et krav er indeholdt i tilbuddet eller ej.Såfremt kravet er markeret som ”delvist opfyldt”, kan der tilknyttes kommentarer i det pågældende felt.Kunden ønsker at kunne vurdere, hvilke optioner der opfyldes med hhv. standardsystem eller udvikling. Derfor skal kravopfyldelseslisten tillige angive, hvorvidt en option opfyldes ved et standardsystem: For en option, der opfyldes ved et standardsystem (basissystem), med evt. opsætning,

markeres opfyldelsen med et S For en option, der opfyldes ved specialtilpasning/udvikling under projektet, markeres

opfyldelsen med U.For en option, hvor opfyldelsen honoreres gennem specialudvikling (U) skal Leverandøren angive prisen for implementering af pågældende option. Leverandøren skal ligeledes angive frist for Kundens bestilling af den pågældende option. Dette skal fremgå af kravopfyldelseslisten, kolonne ”Frist for bestilling af option”.Nedenstående tabel er et eksempel på, hvordan Kravopfyldelseslisten skal udfyldes:

Krav- ID

Krav-type

Opfyldelsesgrad

Standard-grad

Pris i DKK

Frist for bestilling af option

Kommentarer

(Kun ved option - vælg S eller U)

(Kun ved option)

(Kun ved kryds i "delvist opfyldt")

Opfyldt Delvist opfyldt

Ikke opfyldt

3.x MK X3.y K X3.z K X3.æ K X

3.ø O X U 5000 dd.mm.åååå

Implementeres samtidig med funktion XX og YY.

Såfremt Leverandøren intet anfører under kolonnen ’Opfyldelsesgrad’ vil dette blive betragtet som ikke opfyldt, dvs. som ikke indeholdt i tilbuddet.

Side 17 af 198

3.3 LøsningsbeskrivelseUd over kravopfyldelseslisten, skal Leverandøren besvare en række krav i afsnit 9. Hvilke krav der skal besvares fremgår af det samme afsnit 9. Løsningsbeskrivelsen skal referere til krav ID. Desuden opfordres Leverandøren til at besvare kravene fyldestgørende og gerne supplere med eksempler, skærmbilleder o.l., så det bliver nemmere for Kunden at forholde sig til, hvordan den tilbudte løsning rent praktisk kommer til at understøtte Kundens behov.

Side 18 af 198

4. Lovgivning og standarder Dette kapitel indeholder en overordnet beskrivelse af de generelle administrative lovkrav, som det tilbudte system skal kunne understøtte. Med den administrative lovgivning forstås her især forvaltnings-, offentligheds-, arkiv- og persondataloven, men der kan også på specialområder gælde særlovgivning. Herudover indeholder kapitlet en beskrivelse af standarder af både national og international karakter.

4.1 LovgivningDette kapitel indeholder en beskrivelse af de generelle administrative lovkrav, som Løsningen skal overholde og de generelle krav til sagsbehandlingen, som lovene afføder, og som Løsningen skal understøtte. Med den administrative lovgivning er der i denne sammenhæng ment forvaltnings-, offentligheds-, arkiv- og persondataloven.

Ved siden af disse love er der en række offentligretlige grundsætninger, der er relevante for de krav, der stilles til Løsningen. Disse grundsætninger eller principper har bl.a. afsæt i Ombudsmandens fortolkning og udvikling af principperne om god forvaltningsskik. I forhold til Løsningen indebærer det bl.a., at sager, dokumenter og indgående og udgående post skal journaliseres. Endvidere skal myndighedens afgørelser og beslutningsgrundlag arkiveres, ligesom Kunden på en effektiv måde skal kunne fremfinde sager og dokumenter.

4.2 Offentlighedsloven og forvaltningslovenDen gældende forvaltningslov og den gældende offentlighedslov trådte i kraft 1. januar 1987. Forvaltningsloven og offentlighedsloven indeholder en række regler om, hvordan offentlige myndigheder skal tilrettelægge sagsbehandlingen. Nogle af disse krav til sagsbehandling afføder krav til Løsningens funktionalitet:1. I afgørelsessager har offentlige myndigheder pligt til at notere mundtlige oplysninger

vedrørende en sags faktiske omstændigheder, som har betydning for sagens afgørelse. Denne pligt omtales ofte som ”notatpligten”. Kravet om, at sagsbehandleren skal notere relevante oplysninger, der bliver modtaget mundtligt, afføder et behov for, at sagsbehandleren på den enkelte sag kan notere oplysningerne (se kravene om notering på sager i afsnittet 6.1.2, forretningsobjektet Sag).

2. I afgørelsessager vil det normalt følge af god forvaltningsskik, at parten får mulighed for udtale sig i sagen, inden myndigheden træffer afgørelse. Myndigheden har pligt til foretage en høring af parten i forhold til oplysninger, som parten ikke kan antages at vide, at myndigheden er i besiddelse af, og som er af væsentlig betydning for sagens afgørelse. Denne partshøring sker typisk ved, at myndigheden sender et brev til parten med de

Side 19 af 198

relevante informationer og beder parten kommentere dem inden for en bestemt tidsfrist. Partshøring afføder således ikke et nyt selvstændigt behov, der skal understøttes af Løsningen (se kravene til andre typer af høring der er stillet i afsnit 7.1.2, delarbejdsgangen Behandler sag og afsnit 7.1.12, delarbejdsgangen Ekstern høring).

3. Normalt bliver parten gjort bekendt med en myndigheds afgørelse skriftligt. I tilfælde, hvor myndigheden træffer en afgørelse, der er til ugunst for parten, skal afgørelsen være ledsaget af en klagevejledning. Da den enkelte myndighed ofte behandler mange sager inden for det samme emne, har myndigheden et behov for at kunne genbruge en bestemt beskrivelse af, hvilken myndighed afgørelsen kan påklages til og krav til klagens indhold, tidsfrister mv. (se krav om genbrug af standardskrivelser og skabeloncenter under afsnittet 7.2.2, Andre behovstemaer, Automatisering).

4. Regler om aktindsigt findes i både forvaltningsloven og offentlighedsloven. Forvaltningsloven indeholder regler for, hvordan parters begæring om aktindsigt i deres sag skal behandles. Offentlighedsloven fastlægger rammerne for, hvad alle borgere kan kræve at se i den offentlige forvaltning og indeholder sagsbehandlingsregler herom. Kravene til at understøtte myndigheders behandling af begæringer om aktindsigt er beskrevet i afsnit 7.1.13, delarbejdsgangen Behandler aktindsigt.

5. En begæring om aktindsigt skal som udgangspunkt angive den sag, hvis dokumenter der ønskes aktindsigt i. Kravet om, at den person, der ønsker aktindsigt, skal identificere sagen, medfører i forhold til myndigheden, at sagen kan findes. Ved henvendelser fra pressen er kravene i praksis lempeligere. Det betyder, at der skal kunne laves søgninger på emne for at finde materiale frem til pressen (se kravene til at kunne søge og fremfinde sager der er stillet i afsnit 7.2.3 under Andre behovstemaer, Søgning og fremfinding).

6. Begæringer om aktindsigt skal som udgangspunkt behandles inden for 10 dage. I en række andre love er der også indsat en frist for, hvor lang tid den enkelte myndighed har til at behandle en bestemt sag. Kravet om, at en sag behandles indenfor et bestemt tidsrum, afføder et behov for, at myndigheden kan påføre et automatisk advis (se kravene til advis, der er stillet i afsnit 7.1.2, delarbejdsgangen Behandler sag).

7. Kunden er forpligtet til at offentliggøre en række oplysninger om de sager, som Kunden behandler og giver i øvrigt permanent aktindsigt via PVS Online.

8. Kundens erhvervsservicesager er generelt undtaget fra aktindsigt, ligesom patentansøgninger er hemmelige i 18 måneder. Noget lignende gælder for brugsmodel- og designansøgninger.

9. Ifølge forvaltningsloven kan vedkommende minister fastsætte regler om ret til at anvende digital kommunikation ved henvendelser til den offentlige forvaltning og om de nærmere vilkår herfor. Endvidere bliver der i øjeblikket fastsat regler om obligatorisk tilslutning for alle med et CPR-nummer eller et CVR-nummer til postløsningen Offentlig Digital Post (den fællesoffentlige dokumentboks), ligesom en række myndigheder har fastsat regler om obligatorisk digital kommunikation mellem myndighederne og brugerne. Det er derfor et

Side 20 af 198

krav at Løsningen skal kunne håndtere digital kommunikation både via dokumentboksen og via andre kanaler, herunder som sikker e-post.

4.3 ArkivlovenDen gældende arkivlov er sammenfattet i lovbekendtgørelse nr. 1035 af 21. august 2007. Arkivloven fastsætter rammerne for alle offentlige myndigheders arkivalier samt alle offentlige arkivers virksomhed. Ved offentlige arkiver forstås Statens Arkiver samt kommunale eller regionale arkiver, der er oprettet efter arkivlovens § 7. Arkivloven dækker al virksomhed udøvet af den offentlige forvaltning samt domstolene. Loven udstikker bl.a. de overordnede rammer for bevaring og kassation, aflevering samt offentlighedens adgang til myndighedernes arkivalier. For statslige myndigheder gælder det, at de skal aflevere en arkiveringsversion til Statens Arkiver på det tidspunkt, som Statens Arkiver fastsætter. I bekendtgørelse nr. 1007 af 20. august 2010 om arkiveringsversioner er der stillet en række krav til, hvordan afleveringen skal finde sted.Bemærk at kravene vedrørende aflevering til offentligt arkiv er beskrevet under afsnittet 5.1.9, delarbejdsgangen Afleverer til offentligt arkiv.

Håndtering af elektronisk aflevering

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.1 K Håndtering af elektronisk aflevering

Det er et krav, at Løsningen kan leve op til Statens Arkivers regler for elektronisk aflevering fra statslige myndigheder, således at den kan godkendes af Statens Arkiver inden ibrugtagning, og der kan ske en aflevering til offentligt arkiv af data og dokumenter i form af en systemuafhængig arkiveringsversion iht. de gældende regler herfor.

1** 796

4.4 Lov om behandling af personoplysninger Lov om behandling af personoplysninger (”persondataloven”) trådte i kraft den 1. juli 2000 og gælder for behandling af personoplysninger, som foretages af offentlige myndigheder, private

Side 21 af 198

virksomheder, foreninger og lignende. Den gældende lov om behandling af personoplysninger identificeres som lov nr. 429 af 31. maj 2000 med senere ændringer.Begrebet ”behandling” omfatter enhver form for håndtering af oplysninger, der vedrører en person. Som de vigtigste former for behandling kan nævnes: Indsamling, registrering, systematisering, opbevaring, brug, videregivelse, samkøring og sletning.

Loven indeholder regler, som giver den enkelte borger en række rettigheder over for de myn-digheder, virksomheder, foreninger m.v., som behandler oplysninger om den pågældende, herunder retten til at få indsigt i oplysninger om en selv (se afsnittet 7.1.13, delarbejdsgangen Behandler aktindsigt).

Behandling af personoplysninger

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.2 K Produktion af udtræk

Det er et krav, at Løsningen kan producere udtræk af såvel metadata som dokumenter, der skal kunne grupperes efter forskellige kriterier fx tid og sag, således at Kundens behandling af begæringer om egen access (indsigtsret) bliver understøttet, jf. §§ 31-34 i persondataloven.

2* 656

3.3 K Logning af afviste adgangsforsøg

Det er et krav, at Løsningen foretager logning af alle afviste adgangsforsøg. Hvis der inden for en fastsat periode (skal være konfigurerbart) er registreret et nærmere fastsat antal på hinanden følgende afviste adgangsforsøg fra samme arbejdsstation eller med samme brugeridentifikation (skal være konfigurerbart), skal der blokeres for yderligere forsøg, jf. § 18 i bekendtgørelse nr. 528 af 15. juni 2000 om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning (sikkerhedsbekendtgørelsen).

3** 657

Side 22 af 198

Behandling af personoplysninger

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.4 K Logning af anvendelse af personoplysninger

Det er et krav, at Løsningen foretager maskinel registrering (logning) af alle anvendelser af personoplysninger. Registreringen skal mindst indeholde oplysninger om tidspunkt, bruger, type af anvendelse og angivelse af den person, de anvendte oplysninger vedrørte, eller det anvendte søgekriterium (jf. sikkerhedsbekendtgørelsens § 19). Løsningen skal således leve op til de strengeste krav efter sikkerhedsbekendtgørelsen, så det kan anvendes til behandling af alle typer af data, også de mest følsomme.

4 5

3.5 K Håndtering af bevaringsværdige sager og dokumenter

Det er et krav, at Løsningen understøtter, at der ikke må slettes bevaringsværdige sager og dokumenter, som ikke er afleveret til offentligt arkiv.

5 6

3.6 K Håndtering af sletningsfrister

Det er et krav, at Løsningen ikke opbevarer data længere tid end det er nødvendigt af hensyn til de mål, hvortil oplysningerne behandles (jf. Persondataloven).

6 7

3.7 K Beskrivelse af behandling af personoplysninger i Løsningen

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.3 til 3.6.

Info. 1* 716

Bemærk at kravene til brugeradministration og autorisation er beskrevet i afsnit 7.2.5, Andre behovstemaer, Systemadministration.

4.5 Digitale dokumenters bevisværdi

Side 23 af 198

Dansk lovgivning er generelt ikke til hinder for, at en udskrift af et digitalt dokument fremlægges som bevis under en retssag. I dansk ret gælder fleksible bevisretlige regler, som tilgodeser den part, der har handlet forsvarligt ved sin bevishåndtering - reglen om bevisbedømmelsens frihed.IT-sikkerhedsrådets vejledning: ”Digitale dokumenters juridiske bevisværdi” bygger på dansk lovgivning og retspraksis om kravene til dokumentbeviser. Det er rådets opfattelse, at en myndighed, som går frem efter vejledningen, i almindelighed vil kunne føre bevis for indholdet af et digitalt dokument. For bedst muligt at sikre digitale dokumenters bevisværdi skal anbefalingerne i IT-sikkerhedsrådets Digitale dokumenters bevisværdi - Introduktion og vejledning følges, herunder:

Side 24 af 198

Digitale dokumenters bevisværdi

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.8 K Logning af hændelser

Det er et krav, at Løsningen på et hvert dokument kan logge oplysninger om alle hændelser, der har, eller kan have indvirkning på dokumentets integritet. (jf. It-sikkerhedsrådets vejledning, afsnit 5).

7 8

3.9 K Lagring af dokumenter

Det er et krav, at Løsningen for et hvert dokument kan lagre på ikke-sletbare, fabriksnummererede medier, eller i systemer, der kan give en tilsvarende sikkerhed for dokumentets integritet (jf. IT-sikkerhedsrådets vejledning, afsnit 5).

8 9

3.10 K Beskrivelse af logning af hændelser og lagring af dokumenter i Løsningen

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.8 og 3.9

Info. 2* 717

4.6 Fælles offentlig standardisering Kravspecifikationen henviser flere steder til standarder. Standarder af både national og international karakter. Brugen af standarder i denne kravspecifikation har tre forskellige formål:

at kravbeskrive hvorledes gældende og kommende standarder skal efterleves at referere til vedtagne og/eller gældende standarder, hvor det er relevant ift.

Leverandørens forståelse og besvarelse af kravDe relevante standarder vil blive nævnt i de afsnit, hvor de er relevante og standardernes sammenhæng med Løsningen specificeres.

Side 25 af 198

5. AktørerDette afsnit beskriver Kundens krav til Løsningen i forhold til aktører.

Aktører

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.11 K Aktører, som understøttes af Løsningen

Det er et krav, at Løsningen skal kunne understøtte alle nedennævnte aktører:• Personaktører

Bruger (PVS Medarbejder) Systemadministrator Øvrige, dvs. eksterne interessenter

som f.eks. andre myndigheder.• Systemaktører, dvs. systemer og løsningskomponenter, som Løsningen har et behov for at integrere til for at kunne understøtte en sammenhængende opgaveløsning og sagsbehandling.

Se afsnit 8.6 Integration

9** 658

3.12 MK Rettigheder baseret på rolle

Det er et krav, at en bruger skal kunne tildeles forskellige rettigheder baseret på brugerens rolle.

10* 660

3.13 K Antal roller pr. bruger

Det er et krav, at en bruger skal kunne have én eller flere roller. Det skal være nemt for brugeren at skifte mellem disse i forbindelse med brugerens anvendelse af systemet.

11* 797

3.14 MK Definition og opsætning af roller og rettigheder

Det er et krav, at roller og rettigheder kan defineres og opsættes lokalt hos Kunden.

12* 659

Side 26 af 198

6. Forretningsobjekter Løsningen skal anvendeI dette afsnit beskrives de funktionelle krav, der vedrører Løsningens forretningsobjekt-lag. Kravene, der er beskrevet i forretningsobjekt-laget, er kendetegnet ved, at de ikke forholder sig til den procesmæssige understøttelse, men udelukkende omhandler egenskaber ved ”grundelementer” i Løsningen, fx er det på forretningsobjektet sag specificeret, at sag skal have egenskaber der gør, at det er muligt at håndtere forskellige sagstyper, at en sag kan identificeres entydigt mv. Afsnittet indeholder følgende forretningsobjekter:

Arkiv Sag Dokument Interessent Opgaveklassifikation Organisation

6.1 Arkiv – forretningsobjektEt af kerneobjekterne er Løsningens arkiv. Løsningen skal som minimum indeholde ét forvaltningsmæssigt arkiv. Det vil sige et arkiv, som rummer alle Kundens sager, dokumenter og tilhørende relationer. Et forvaltningsmæssigt arkiv er reguleret af lovgivning i forhold til anvendelse, bevaring og kassation. Det er derfor centralt, at Kunden kan adskille det eller de forvaltningsmæssige arkiver fra eventuelle andre arkiver. Et forvaltningsmæssigt arkiv skal tilsvarende kunne defineres som sagsuafhængigt, således at Kunden, der knytter visse af sine forvaltningsmæssige dokumenter op til eksempelvis hændelser eller aktiviteter, kan arkivere retmæssigt i arkivet med henblik på en systemstøttet aflevering til offentligt arkiv.Udover et forvaltningsmæssigt arkiv skal Løsningen kunne etablere en ønsket arkivstruktur bestående af et i teorien valgfrit antal delarkiver. Delarkiverne kan være af forskellig type og have forskellige formål og karakteristika. Udover et forvaltningsmæssigt arkiv skal Løsningen kunne oprette referencearkiver til håndtering af information uden sagsbinding og afleveringspligt, men med almen relevans for Kunden. Det kan fx være lovtekster, direktiver, fraser mv. Yderligere skal det være muligt at oprette arkiv til opbevaring af medarbejdernes personlige data, informationer mv.Arkivstrukturen skal afspejle Kundens struktur. Kunden dækker i denne sammenhæng alle de organisatoriske enheder, som gør brug af Løsningen og deres indbyrdes sammenhæng. Kunden, NPI og Ankenævnet skal i systemet være udtrykt ved hvert sit delarkiv, der sikrer korrekt adskillelse og opdeling af sager og/eller dokumenter for de tre myndigheder, der har

Side 27 af 198

indgået et administrativt servicefællesskab. Adskillelsen mellem myndighedernes delarkiver skal sikres gennem konfiguration af brugerrettigheder.Arkivstrukturen skal samtidig afspejle Kundens brug af forvaltningsmæssig registrering og registreringssystematik. Kundens arkivstruktur skal kunne opdele sager og/eller dokumenter efter registreringssystematik.

Arkiv – forretningsobjekt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.15 K Arkivtyper

Det er et krav, at Løsningen kan danne ramme for en logisk opdeling af det lagrede materiale ud fra arkivtyperne:• forvaltningsmæssigt arkiv• referencearkiv (Dokumentcontainer)• personligt arkiv

91 92

3.16 K Forvaltningsmæssigt arkiv

Det er et krav, at Løsningen og dets tilhørende database etablerer og skaber det ’forvaltningsmæssige arkiv’. Alle sager, dokumenter og registreringer af forvaltningsmæssig karakter skal således kunne arkiveres/foretages i Løsningen.

92 93

3.17 K Etablering af et forvaltningsmæssigt sagsarkiv

Det er et krav, at der i Løsningen kan oprettes et forvaltningsmæssigt sagsarkiv, hvor sager, sagsdokumenter og øvrige sagsregistreringer arkiveres.

93 94

3.18 K Obligatorisk sagstilknytning i forvaltningsmæssigt sagsarkiv

Det er et krav, at det ikke er muligt at lagre dokumenter uden sagstilknytning i det forvaltningsmæssige sagsarkiv.

94 95

Side 28 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.19 K Sagsuafhængigt forvaltningsarkiv

Det er et krav, at Løsningen kan oprette et forvaltningsmæssigt delarkiv uden obligatorisk brug af sagsbegrebet i Løsningen.

95** 798

3.20 K Personligt arkiv

Det er et krav, at Løsningen kan stille et dokumentarkiv til rådighed, hvor det er muligt for Kundens medarbejdere at lagre informationsmateriale - uden sagstilknytning - af mere personlig karakter. Fx information, udkast og idéer, der ikke nødvendigvis skal indplaceres i et reference- eller forvaltningsmæssigt arkiv på et senere tidspunkt.

96* 669

3.21 K Brug af registreringssystematik ved overførsel til forvaltningsmæssigt arkiv

Dokumenter i personligt delarkiv skal kunne overføres til et reference- eller forvaltningsarkiv. Det skal i forbindelse med overførsel af dokumenter kunne gøres obligatorisk at følge Kundens registreringssystematik.

97* 670

3.22 K Dokumentcontainer for relaterede systemer

Det er et krav, at Kundens øvrige dokumentproducerende systemer kan gøre brug af Løsningens arkiv (som dokumentsilo) til arkivering af dokumenter. Der skal kunne dedikeres et delarkiv (forvaltningsmæssigt arkiv eller referencearkiv) til et eller alle dokumentproducerende systemer.

98* 663

Side 29 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.23 K Dokumenter i faglige sagsbehandlingssystemer

Det er et krav, at dokumenter, som skabes i faglige sagsbehandlingssystemer, og som enten gør brug af et eget systemarkiv eller et referencearkiv i Løsningen, skal kunne gemmes som sagsakter i systemet ved overførsel til/arkivering i et forvaltningsmæssigt delarkiv i Løsningen.

99 100

3.24 K Lagring af information på baggrund af kontekst

Det er et krav, at Løsningens arkiv kan lagre information i logiske enheder på baggrund af en kendt systemmæssig sammenhæng og kontekst. Fx alle sager og dokumenter mv. indenfor et specifikt område.

100 101

3.25 K Beskrivelse af arkivet i Løsningen

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.24.

Info. 24*

719

6.2 Sag – forretningsobjektEn sag består af et antal dokumenter, der vedrører det samme begivenhedsforløb. Begrebet kan sammenlignes med det fysiske omslag, der holder sammen på et antal dokumenter. En sags egenskaber bestemmes af dens sammenhænge til andre forretningsobjekter og indeholder en række beskrivende oplysninger, så som ansøgningsnummer, journalnummer, interessentoplysninger, tidspunkt for sagens oprettelse, organisatorisk tilhørsforhold mv.De dokumenter og oplysninger, der udgør en sag, kan således betragtes som henholdsvis selvstændige størrelser og som del af et sagskompleks. Alle sager skal i systemmæssig forstand betragtes som og oprettes som enkeltsager.Kunden gør især brug af enkeltsager, løbende sager samt projektsager.

Enkeltsag : Dokumenter og øvrige oplysninger, som tilsammen afspejler én bestemt administrativ proces, eller som omhandler et bestemt emne, forløb, begivenhed eller problem. Ombudsmanden beskriver en enkeltsag som "de oplysninger der ligger til

Side 30 af 198

grund for en afgørelse". Udgangspunktet for journalisering af sager er, at de skal oprettes som enkeltsager.

Løbende sager : Hvis det ikke er muligt på en gennemskuelig/logisk måde at oprette enkeltsager, oprettes løbende sager. Dette kan være information vedr. møder i en arbejdsgruppe i en periode på typisk et år, f.eks. ”Høringer fra offentlige myndigheder”.

Projektsag , hvor de enkeltsager, der tilsammen udgør dokumentation af et projekt, er et synonym for en samlesag.

Samlesag, hvor oplysninger om en bestemt rettighed, en bestemt erhvervsserviceopgave et bestemt forvaltningsemne eller forvaltningsopgave er samlet.

Kundens brug af sagsbegrebet er endvidere afspejlet i Kundens datamodel, se Underbilag 3.3

Side 31 af 198

Sag – forretningsobjekt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.26 K Løsningen skal omfatte et sagsbegreb

Det er et krav, at Løsningen understøtter et sagsbegreb, som gør det muligt at håndtere både simple og komplekse sager – herunder:• håndtering af forskellige sagstyper med forskellige egenskaber (metadata-felter), definitioner og tilhørende værdilister• registrering og tilknytning af dokumenter, interessenter og aktiviteter til sager• at sager kan identificeres ved et globalt unikt sagsid, der skal kunne udveksles med andre systemer• at sager kan indeholde struktureret og samlet information om de hændelser/aktiviteter, der er sket i et sagsforløb• at enkeltsager kan præsenteres som del af en samlesag

101** 703

3.27 K Operationer på sager

Det er et krav, at en bruger kan foretage en række sædvanlige operationer på en sag, som de ville kunne gøre med papirsager – herunder:• at kunne tilføje dokumenter til én eller flere sager• at kunne foretage løbende journalnotater på sagen• at kunne knytte ”gule lapper” med kommentarer til sagen.• at kunne identificere de sager, hvori et givet dokument indgår og gå direkte til de pågældende sager• mulighed for løbende at opdatere metadata og omjournalisere sager

102 103

Side 32 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.28 K Beskrivelse af sagsbegreb og -operationer

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.26 og 3.27.

Info. 25*

720

3.29 MK Betegnelse af sager i forbindelse med sagsoprettelse

Det er et krav, at der i forbindelse med oprettelse af en sag er mulighed for at anvende forskellige sagsbetegnelser på baggrund af Kundens beslutning om at anvende bestemte, men forskellige sagsbetegnelser. Det betyder, at når der oprettes en prædefineret sagstype såsom en patentsag, varemærkesag mv., tilkobles de relevante felter til registrering af relaterede data automatisk.

103** 601

3.30 K Automatisk forslag til sagsbegreb

Det er et krav, at Løsningen som udgangspunkt tilbyder at oprette en sag som en enkeltsag. Dog skal Løsningen, på baggrund af Kundens beslutning om forhold til givne emner (fx rettighedssager eller projektsager), automatisk tilbyde brugeren at anvende det sagsbegreb fx samlesag mv., som Kunden har besluttet at bruge ved oprettelse af sager indenfor det givne emne.

104** 602

3.31 K Angivelse af sagsfase

Det er et krav, at det er muligt, at angive sagens fremdrift i forhold til det samlede sagsforløb ved markering af, hvor langt behandlingen af sagen er, ud fra de prædefinerede trin i sagsbehandlingen

105** 697

Side 33 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.32 K Angivelse af sagsstatus

Det er et krav, at Løsningen kan håndtere en markering af sagens status. Det kan ske enten ved, at brugeren manuelt påfører en status eller, at Løsningen automatisk kan angive en status på sagen. Fx ved, at der er opsat et brugerdefineret tidsinterval, eller at der er gennemført en bestemt handling, der medfører, at en sag skifter fra aktiv til passiv.

106 107

3.33 K Beskrivelse af mulighed for anvendelse af sagsfase og sagsstatus

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.31 og 3.32.

Info. 26*

721

3.34 MK Genåbning af afsluttet sag

Det er et krav, at en ”afsluttet” sag kan genåbnes af en bruger med rettigheder til at genåbne sager.

107 108

3.35 K Logning/’Stempling’ af sagshandlinger på sagen til dannelse af log

Det er et krav, at handlinger og statusmarkeringer, der tilføjes under sagsbehandlingsarbejdet, automatisk registreres, så der kan dannes og præsenteres en log med tydelig historik på alle ændringer foretaget på sagen.

108 109

3.36 K Beskrivelse af bagvedliggende logning/stempling på sagen


Info. 27*

722

Side 34 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.37 K Sikkerhed på sag

Det er et krav, at Løsningen understøtter adgangsbegrænsning til sagen. Løsningen skal således sikre, at sagen oprettes med en standard adgangsbegrænsning, og at brugeren kun kan ændre adgangsbegrænsningen indenfor de rammer brugeren er givet ifm. systemopsætningen

109 110

3.38 MK Sletning af dokumenter og data på patentsager Det skal være muligt at kunne slette dokumenter og data på patentsager. De eneste data, der ikke skal slettes, er sagens løbenummer og ansøgningsdatoen.

- 537

3.39 K Adgangsbegrænsning på bruger-, enheds- og rolleniveau

Det er et krav, at Løsningen kan arbejde med adgangsbegrænsning på både bruger, enheds- og rolleniveau. Det skal fx være muligt at begrænse adgangen til sagen til udvalgte brugere, en specifik afdeling og/eller en række brugere med en specifik rolle i enheden eller myndigheden. Det kan fx være sager som kun brugere med rollen ’ledere’ må have adgang til – enten i en afdeling eller i hele myndigheden.

110 111

Side 35 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.40 K Masseændring af sager

Det er et krav, at det på baggrund af en søgning skal være muligt at masseændre alle eller en del af de fremsøgte sager, herunder:• at afslutte sager• at genåbne sager• at ændre prædefinerede sagsgange og ændre metadata• at overføre sagsansvar fra en sagsbehandler til en anden• overføre sagsansvar fra en organisatorisk enhed til en anden

111 112

3.41 K Rettigheder til masseændring af sager

Det er et krav, at rettighederne til masseændring af sager kan differentieres pr. rolle (jf. afsnit 5 Aktører). Fx skal det være muligt at opsætte rettighederne, således at en systemadministrator kan foretage alle masseændringer af sager, mens en bruger kun må kunne ændre overdragelse af sagsansvar til anden bruger og afslutning af egne sager.

112 113

3.42 K Beskrivelse af funktionalitet til masseændring på sager

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i Krav 3.41.

Info. 28*

723

3.43 K Kopiering af sager

Det skal være muligt at oprette en ny sag på baggrund af dokumenter og metadata kopieret fra en anden sag. Det skal være muligt for den enkelte sagsbehandler at udvælge, hvilke data og dokumenter der skal kopieres.

- 662

Side 36 af 198

6.3 Dokument – forretningsobjektEt dokument består af en afgrænset samling af informationer, i en kendt struktur, gemt på et kendt medie. Et dokument kan foreligge på papir, digitalt medium, mikrofiche, eller et hvilket som helst andet medie, der kan være bærer af information. Dokumenter kan rumme tekst, tegninger, grafik, fotografier, video, tale osv.Et digitalt dokument er en sammenhængende mængde af data. Dokumenterne i Løsningen vil oftest være digitale (skriftlige) dokumenter, men kan også være lydfiler, billedfiler, grafik filer, filer fra grafiske informationssystemer, databaser, regneark mv. Et dokument kan indgå i et arkiv sammen med eller adskilt fra sagen.Et digitalt dokument kan foreligge i flere versioner, hvilket betyder at systemet gemmer alle udgaver af dokumentet, fra det oprettes i kladdetilstand, til det foreligger i en færdig udgave. Derudover kan et dokument foreligge i flere færdige udgaver, det der sædvanligvis kaldes revisioner eller ’store versioner’ (fra engelsk: ’major’ og ’minor versions’). Revisioner er vigtige i rettighedssager, projektsager, administrative sager mv., hvor der er behov for let at kunne fremfinde og dokumentere en låst udgave af et dokument på en sag. Det kan fx være en specifik revision/udgave af en kontrakt eller anden aftale, der skal kunne dokumenteres tidsligt.Et dokument kan bestå af et hoveddokument og et eller flere underdokumenter. Et underdokument kan principielt indgå i flere hoveddokumenter. Samme dokument kan i forskellige sammenhænge være hoveddokument henholdsvis underdokument.Et vigtigt element i Løsningen knyttet til dokumentet er journalposten. Journalposten kan også kaldes dokumentkortet og er bindeleddet mellem sagen og dokumentet. Det er på journalposten, at metadata om dokumentet er registreret. Journalposten er således bærer af dokumentets centrale metadata. Handlinger foretaget på journalposten kan have indflydelse på dokumentet. Fx vil låsning af journalposten afstedkomme låsning af dokumentet. Låsning af en dokumentversion betyder modsat ikke nødvendigvis låsning af journalposten. Tilsvarende vil det ofte være metadataopmærkningen på journalposten, der indplacerer dokumentet i et specifikt arkiv eller delarkiv og dermed anviser, hvilke afleveringsmæssige hensyn dokumentet er omfattet af. Funktionalitet knyttet til forretningsobjektet Dokument forventes stillet til rådighed af forretningstjenesten af samme navn. Denne forretningstjeneste er med hensyn til tekniske krav beskrevet i afsnit 8, Ikke-funktionelle krav.

Side 37 af 198

Dokument – forretningsobjekt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.44 MK Understøttelse af forskellige slags digitale dokumenter

Det er et krav, at Løsningen kan understøtte arbejde med forskellige slags digitale dokumenter fx:

• tekstfiler

• lydfiler

• billedfiler

• grafikfiler

• videofiler

• databaser

• regneark

113 114

3.45 K Associering af dokumenter til relevant applikation

Det er et krav, at Løsningen kan indstilles til at gøre brug af det relevante program, når et dokument skal åbnes eller bearbejdes som del af sagsbehandlingen. Åbning af et specifikt program skal kunne variere afhængigt af:• filformat (TXT, DOC, ODT, PDF, XLS mv.)• brugerhandling/-behov (Rediger/Vis)

114* 664

3.46 K Versionstyring - visning af versioner

Det er et krav, at alle versioner af et dokument skal kunne vises på den tilknyttede journalpost.

115 116

3.47 K Versionsstyring – seneste version som standard

Det er et krav, at brugeren kan se, hvilken version, der er den nyeste og sætte systemet op til, som udgangspunkt, at vise seneste version af dokumentet som standard.

116 117

Side 38 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.48 K Versionsstyring – sporbarhed ift. gældende versioner og ændringer

Det er et krav, at det er muligt at se, hvilke ændringer, der er foretaget i forhold til tidligere versioner.

117 118

3.49 K Versionsstyring – udgangspunkt i tidligere versioner af dokument

Det er et krav, at brugeren kan arbejde videre med en vilkårlig tidligere version af et givet dokument. En låst version skal således kunne benyttes som udgangspunkt for en ny version af et dokument og skal kunne gemmes på samme journalpost, eller være udgangspunkt for dannelse af en ny journalpost

118 119

3.50 K Versionsstyring – versioner i forskellige formater

Versionsstyringen skal kunne håndtere at egenproducerede dokumenter kan gemmes i forskellige formater på samme version. At en vilkårlig version af et dokument fx findes som både tekst- og pdf-format.

119 120

3.51 K Versionsstyring – låsning af dokumentversion

Det er et krav, at Løsningen understøtter låsning på versionsniveau uden, at det afstedkommer låsning af selve journalposten.

120 121

Side 39 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.52 K Versionsstyring – understøttelse af revisioner af dokumenter

Det er et krav, at Løsningen understøtter, at et dokument i en vilkårlig version kan ophøjes til en færdig revision af dokumentet. At gøre et dokument til en revision skal afstedkomme, at den reviderede udgave af dokumentet kan fremvises i uændret stand på et senere tidspunkt. Det skal fortsat være muligt at arbejde videre med dokumentet, men i en ny version tilhørende en ny revision.

121 122

3.53 K Dokumentegenskaber – hoved- og underdokumenter

Det er et krav, at et dokument kan bestå af et hoveddokument og et eller flere underdokumenter. Et underdokument skal kunne indgå i flere hoveddokumenter, og samme dokument kan i forskellige sammenhænge være hoveddokument henholdsvis underdokument.

122 123

3.54 K Dokumentegenskaber - tildeling af rolle på dokument

Det er et krav, at det er muligt at anvise på dokumentet, hvilken rolle det har. Fx at dokumentet er hoveddokument ift. en specifik journalpost på en sag, og at der er anvist en given sammenhæng med et relateret underdokument/bilag.

123 124

Side 40 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.55 K Dokumentegenskaber - tildeling af status på dokumentet

Det er et krav, at det er muligt at tildele dokumenter status, således at man kan se færdiggørelsesgraden af et dokument. Yderligere skal man kunne se om, eller hvilken version, der fx er sendt til offentliggørelse eller i intern høring. Status skal kunne påføres/ændres af både en bruger- og systemaktør, således at det fx kan angives automatisk, når dokumentet sendes i høring.

124 125

3.56 K Dokumentegenskaber – tildeling af dokumentstatus

Det er et krav, at Løsningen kan håndtere dokumentstatusser, herunder dokumentstatus ”kladde”, og at disse statusser skal kunne defineres lokalt hos Kunden.

125* 604

3.57 K Dokumentegenskaber - håndtering af dokumenttyper

Det er et krav, at Løsningen kan håndtere dokumenter af forskellig type (”kategori”), fx indgående brev. Fx vil en søgning på dokumenter til udarbejdelse af en åben postliste forudsætte, at systemet kan finde de dokumenter, der har karakter af breve (udgående og/eller indgående breve), men ikke interne dokumenter (eksempelvis notater) lagret i systemet. Kunden skal selv kunne definere de ønskede dokumenttyper omfattet af postlistevisning.

126* 605

Side 41 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.58 K Dokumentegenskaber - redigerbar / ikke-redigerbar

Det er et krav, at Løsningen kan håndtere, at dokumenter enten er redigerbare eller ikke-redigerbare. Dokumenter, der er modtaget udefra som redigerbare (fx per e post) skal hurtigst muligt efter modtagelsen sikres mod ændringer (jf. spørgsmålet om digitale dokumenters bevisværdi). I andre tilfælde ændres dokumentets redigerbarhed over tid. Således vil et egenproduceret dokument i form af fx et udgående brev i starten være redigerbart (fx status ”kladde”), men samtidig med afsendelsen skal det ”fastfryses” til at være ikke-redigerbart (endeligt).

127 128

3.59 K Journalisering - nedarvning af sikkerhed fra sag

Det er et krav, at Løsningen understøtter nedarvning af sikkerhed fra sagen, hvis dokumentet oprettes/journaliseres fra en sag, eller tilknyttes en sag ifm. journalisering.

129 130

3.60 K Journalisering - journalisering af dokument iht. prædefineret klassifikation

Det er et krav, at et dokument kan journaliseres i henhold til Kundens prædefinerede klassifikation.

131** 635

3.61 K Journalisering - sammenknytning af dokumenter ifm. journalisering

Det er et krav, at Løsningen kan knytte relevante dokumenter sammen i forbindelse med journaliseringen, fx ansøgning – svar, høring – høringssvar, mail – vedhæftede bilag etc.

134 135

Side 42 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.62 K Journalisering – massejournalisering og masseopdatering af dokumenter

Det er et krav, at en sagsbehandler kan gennemføre massejournalisering af og masserettelser af metadataoplysninger på dokumenter. Fx at det er muligt at påføre identiske metadata for en lang række dokumenter i en og samme arbejdsgang.

135 136

3.63 K Beskrivelse af funktionalitet til massejournalisering

Leverandøren skal beskrive, hvordan Løsningen opfylder behov beskrevet i Krav 3.62.

Info. 32*

727

3.64 K Journalisering - låsning af indgående dokument ifm. journalisering

Det er et krav, at et indgående dokument automatisk låses i det øjeblik dokumentet er journaliseret.

136 137

3.65 K Journalisering - automatisk låsning af dokumenter

Det er et krav, at låsning af dokumenter skal kunne ske automatisk på baggrund af aktiviteter, der sker med dokumenter. Efter låsning af dokumenter må det ikke være muligt at ændre i dokumentet.

Se afsnit 7.1.8 Opretter og behandler dokument.

137* 799

3.66 K Journalisering - tilknytning af dokument til en sag

Det er et krav, at Løsningen kan knytte et dokument til en sag, herunder flytte eller kopiere det fra én sag til en anden.

138 139

Side 43 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.67 K Journalisering - udfyldelsen af metadatafelter

Det er et krav, at Løsningen kan automatisere udfyldelsen af metadatafelter, hvor det er muligt og indlysende. Dette gælder både obligatoriske, uredigerbare felter som fx dokumentID, oprettelsesdato etc., og redigerbare felter som fx titel, dokumenttype, mv.

139 140

3.68 K Journalisering – indplacering i prædefineret klassifikation

Det er et krav, at Løsningen i forbindelse med oprettelse og journalisering af et dokument giver brugeren mulighed for at indplacere dokumentet i Kundens prædefinerede klassifikation via metadataopmærkning på journalposten.

140** 606

3.69 K Journalisering - påføring af metadata i dokumentets levetid

Det er et krav, at der kan påføres metadata på Journalposten i hele dokumentets levetid dækkende den registrering, der sker ifm.: • oprettelse af dokumentet• redigering af dokumentet• færdiggørelse af dokumentet

141 142

3.70 K Journalisering - validering af registreringer

Det er et krav, at Løsningen kan foreslå registreringer ifm. journaliseringen af dokumentet, som brugeren skal kunne ændre eller validere

142 143

Side 44 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.71 K Journalisering – omjournalisering af dokument

Det er et krav, at det er muligt at omjournalisere et dokument. Her tænkes på, at det for brugeraktør med rettigheder hertil skal være muligt at ændre et dokuments indplacering i benyttet registreringssystematik mv.

143** 607

3.72 K Journalisering - automatisk registering/nedarvning til dokumenter

Det er et krav at handlinger og statusmarkeringer, der tilføjes under sagsbehandlingsarbejdet, uden videre manuel foranstaltning, kan medføre registreringer på dokumentet, fx ændringer i sikkerhed.

144 145

3.73 K Løbende ændring af sikkerhed på dokument

Det er et krav, at Løsningen giver mulighed for, at ændre sikkerheden på et dokument, således at adgangen til et dokument udvides eller indsnævres efter behov, fx skal en bruger med rettighed til det kunne tildele andre brugere adgang til dokumentet. Tilsvarende skal systemet ved intern høring eller godkendelse kunne tildele personer, omfattet af høringen, midlertidig adgang til dokumentet.

145 146

3.74 K Logning af ændringer på dokumentniveau

Det er et krav, at Løsningen kan logge data for alle ændringer, der foretages på dokumentet.

146 147

3.75 K Håndtering af påtegninger/gule sedler

Det er et krav, at Løsningen kan håndtere ”påtegninger/gule sedler” på dokumenter, herunder versionering og håndtering af arkiveringsudgaver af disse.

147 148

Side 45 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.76 K Notering af oplysninger på sagen

Det er et krav, at Løsningen kan understøtte sagsbehandlerens behov for at dokumentere de mundtlige oplysninger, der ligger til grund for en afgørelse.

148 149

3.77 K Modtagelse/indhentning af dokumenter fra filsystemet og andre systemer

Det er et krav, at dokumenter kan hentes ind i systemet fra det almindelige filsystem på en nem og intuitiv måde. Med filsystem forstås lokale drev, netværks-drev, disketter eller andre medier.

149* 150

3.78 K Fordeling af dokumenter

Det er et krav, at Løsningen indeholder faciliteter til fordeling af egenproducerede dokumenter til modtagerenhed/person – uanset om om det oprettes og behandles fra kontorautomatiseringssystemet eller fra Løsningen.

150** 638

3.79 K Modtagelse af dokumenter fra filsystemet og andre systemer - automatisk overførsel af dokumenter til Løsningen

Det er et krav, at dokumenter automatisk kan overføres (push) til Løsningen fra filsystemer, disketter eller andre medier.

151* 152

6.4 Interessent – forretningsobjekt Den 1. juli 2012 var der cirka 7 millioner interessenter i Kundens interessentregister. Blandt andet på grund af importer af data fra internationale organisationer er der hver måned behov for at slette et større antal interessenter; den 1. juli 2012 blev der slettet næsten 7.000 interessenter.

Side 46 af 198

Interessent – forretningsobjekt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.80 K Internt interessentregister (navne- og adressedatabase)

Det er et krav, at Løsningen kan stille et internt interessentregister til rådighed med oplysninger om de personer, virksomheder m.fl., som Kunden korresponderer med, således at det kun er nødvendigt at oprette navn og adresse i systemet én gang.

153** 636

3.81 K Håndtering af forskellige typer af interessenter

Det er et krav, at systemet kan håndtere forskellige typer af interessenter. Det skal endvidere være muligt at opsætte forskellige regelsæt for validering af de enkelte typer.

- 641

3.82 K Hente navne og adresser fra andre databaser/registre

Det er et krav, at Løsningen kan hente navne og adresser fra andre såvel interne som eksterne registre og databaser, herunder CVR og CPR. Det gælder både ifm. sagsbehandlingen, og som del af en automatiseret og skeduleret opdatering.

154** 609

3.83 K Overførsel af interessenter/adresser fra andre databaser/registre

Det er et krav, at Løsningen automatisk kan overføre interessenter hentet fra andre databaser ifm. sagsbehandlingen til det interne interessentregisterregister.

155** 691

3.84 MK Håndtering af udenlandske adresser

Det er et krav, at Løsningen kan håndtere udenlandske adresser.

156 157

Side 47 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.85 K Ingen begrænsning på antal indeholdte interessenter

Det er et krav, at Løsningens interessentregister kan indeholde et i princippet frit antal interessenter.

157** 800

3.86 K Genbrug af (dele af) adresser ved nyoprettelse af adresser

Det er et krav, at Løsningen kan håndtere genbrug af adresser/dele af adresser ved oprettelse af nye adresser, fx således at oplysninger om en firmaadresse kan genbruges, hvis der ønskes oprettet yderligere adresser for firmaet, men med tilknyttet ”attention” person.

158* 693

3.87 K Vedligehold af adresser

Det er et krav, at der sker en vedligeholdelse af adresser, fx således at et antal interessenter med fælles postadresse kan ændres under ét, når postadressen ændres

159** 639

3.88 K Adgangsbegrænsning på adressedatabase

Det er et krav, at der kan skabes adgangsbegrænsninger (læse-/skriverettigheder) til adressedatabasen, eller dele af denne, samt at administrator får muligheder for at kontrollere, at der ikke sker unødvendige dobbeltregistreringer, eller andre uhensigtsmæssige ændringer i databasen

160** 698

3.89 K Oprettelse af grupper

Det er et krav, at der kan dannes grupper af enkeltadresser, fx adresserne på medlemmerne af et tværministerielt udvalg, således at brugeren kun behøver at tilknytte gruppen til udgående post.

161 162

Side 48 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.90 K Dokumentation af adresse på tilknytningstidspunkt

Af dokumentationshensyn er det et krav, at en adresse eller en gruppe af adresser, der tilknyttes et ind- eller udgående brev, altid senere vises i den form, som adressen eller adressegruppen havde på tilknytningstidspunktet, når den vises i forbindelse med det pågældende dokument – også selv om der efterfølgende er sket ændringer i adressen, fx ny postadresse.

162 163

3.91 K Indhentning af person/organisationsspecifikke metadata fra eksternt register

Det er et krav, at Løsningen for sagstyper, hvor en person, en organisation eller en virksomhed er sagens hovedemne kan indhente data fra eksterne registre til autoudfyldelse af person/organisationsspecifikke metadatafelter på baggrund af webservicekald eller opslag.

164 165

3.92 K Interessentoprettelse på sag eller dokument via centralt register

Det er et krav, at Løsningen kan hente interessentoplysninger fra et eksternt interessentregister i forbindelse med oprettelse af en interessent på en sag eller et dokument.

165* 704

3.93 K Medtage afsender/modtager som en del af metadata

Det er et krav, at Løsningen, for så vidt angår e-post, kan medtage interessenten på baggrund af afsender/modtagers domæne, som en del af metadata i forbindelse med journalisering af den indgående e-post

166* 705

Side 49 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.94 K Ensartet proces for interessenttilknytning og -oprettelse

Det er et krav, at Løsningen understøtter en ensartet brugerproces for interessenttilknytning på sag/dokument og evt. oprettelse i internt interessentregister uanset om interessenten hentes fra internt eller eksternt interessentregister.

167* 706

3.95 K Sammenhæng mellem interessent i register og interessent på sag

Det skal være muligt i Løsningen, at se sammenhængen mellem en interessent i Løsningens register og de sager, hvor interessenten er tilknyttet med en specifik rolle ift. sagen og/eller dokumentet. Det skal tilsvarende være muligt at skærme af for sammenhængen i de tilfælde, hvor overblikket på tværs af sagsområder kan være i strid med dataloven.

168* 707

3.96 K Beskrivelse af funktionalitet til interessenttilknytning på sager/dokumenter

Leverandøren skal beskrive, hvordan Løsningen opfylder behov beskrevet i krav 3.95.

Info. 36*

731

3.97 K Brug af komponent til interessenthåndtering fra 3.parts-leverandør

Det skal være muligt, hvis Kunden ønsker det, at gøre brug af en interessentkomponent fra 3. partsleverandør, som alternativ til Løsningens interessentkomponent.

169* 610

Side 50 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.98 K Dekobling af interessenthåndteringen

Det skal være muligt i Løsningen at dekoble forretningsobjektet Interessent helt eller delvist, hvis Kunden ønsker at benytte en 3. partskomponent til interessenthåndteringen.

170** 672

3.99 K Beskrivelse af mulighed for brug af 3. partskomponent til interessenthåndtering

Leverandøren skal beskrive, hvordan Løsningen opfylder behov beskrevet i krav 3.98.

Info. 37*

732

3.100 K Sletning af interessenter

Det er et krav, at det skal være muligt at fremfinde og slette interessenter, hvor der eksempelvis ikke er tilknyttet sager eller dokumenter. Sletning betyder her, at interessenterne overføres til en status, som angiver, at de er inaktive.

- 587

3.101 K Masseflytning af interessent-sag relation

Det skal være muligt at foretage masseflytning af relationer mellem sager og interessenter.

- 588

6.5 Opgaveklassifikation - forretningsobjektForretningsobjektet Opgaveklassifikation svarer til den generelle beskrivelse af en myndigheds opgaver i en systematik eller klassifikation. Forretningsobjektet Opgaveklassifikation beskriver de funktionelle behov i forbindelse med understøttelsen af klassificering af sager og dokumenter i myndigheden. Forretningsobjektet Opgaveklassifikation bruges som journalnøgle for sagen og har relation til de retskilder, der fastsætter opgaven. Opgaven kan udføres af eller fastsættes af en myndighed.Sagsbehandlerne skal nemt kunne foretage registreringer på en sag eller et dokument, således at de ikke skal afbryde selve sagsbehandlingen. Det betyder, at der er behov for, at registreringsopgaven er en så integreret del af selve sagsbehandlingen som muligt. Det er af afgørende betydning for en effektivisering og lettelse af sagsbehandlernes arbejdssituation, at de metadata, der modtages eller dannes, med så høj grad af automatik som muligt, kan påføres sagen og/eller dokumentet.

Side 51 af 198

Opgaveklassifikation – forretningsobjekt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.102 K Implementering af Kundens sagstyper og dokumenttyper

Det er et krav, at Løsningen kan understøtte de sagstyper og dokumenttyper Kunden ønsker at anvende.

Se Underbilag 3.3 Datamodel

172** 611

3.103 MK Automatisk fangst af metadata

Det er et krav, at Løsningen kan fange allerede eksisterende metadata ved hjælp af OCR, stregkoder, oplysninger tastet ind af brugere af fx elektroniske blanketter, og lignende metoder. Disse data skal gives som forslag til relevante metadata i forbindelse med journalisering (præjournaliserning).

174** 612

3.104.

K Beskrivelse af automatisering ved påføring af metadata


Info. 39*

733

3.105 K Påføring af metadata i løbet af sagens levetid

Det er et krav, at brugerne kan påføre metadata på forskellige tidspunkter af sagens eller dokumentets levetid.

175 176

3.106 K Beskrivelse af påføring af metadata i løbet af sagens levetid


Info. 40*

734

Side 52 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.107 MK Oprettelse af nye metadata typer

Det er et krav, at Løsningen indeholder faciliteter, således at Kunden selv kan definere og anvende nye metadata typer. Det er vigtigt, at sådanne faciliteter er ”nemme” at bruge, dvs. at den ikke kræver programmørindsats, og at det er fleksibelt og hurtigt at definere nye metadata typer.

178* 613

3.108 K Beskrivelse af tilpasning/oprettelse af metadatatyper på sagsniveau


Info. 41*

735

3.109 K Dokumentation af historik på metadata

Det er et krav, at Løsningen kan registrere oplysninger på både dokumenter og sager med historik på alle metadata.

179 180

3.110 MK Omregistrering iht. prædefineret klassifikation

Det er et krav, at brugeren kan omregistrere metadata på sager i henhold til Kundens prædefinerede klassifikation.

180* 614

3.111 K Præsentation af sagstyper og dokumenttyper

Det er et krav, at der forefindes forskellige præsentationsformer af sagstyperne og dokumenttyperne fx den traditionelle hierarkiske fremstillingsform og pick-lister. Blandt andet med fokus på mulige afvigelser ift. præsentationsform

181** 182

3.112 K Beskrivelse af funktionalitet til Kundens sagstyper og dokumenttyper


Info. 42*

736

Side 53 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.113 K Opsætning af standardværdier – globalt, lokalt og personligt

Det er et krav, at det er opsætbart, hvilke metadata Løsningen skal foreslå. Opsætningen skal kunne foretages centralt og gælde for alle brugere og/eller lokalt og gælde for den enkelte bruger eller brugerprofil.

182 183

3.114 MK Masseopdatering - gennemførsel af masse-opdatering

Det er et krav, at Løsningen kan gennemføre masseopdatering/-rettelser af metadata-oplysninger på tværs af sager.

183 184

3.115 K Markering af handlinger og status på sagen

Det er et krav, at handlinger og statusmarkeringer på sagen, som tilføjes under sagsbehandlingsarbejdet, uden videre manuel foranstaltning medfører registreringer på sagen/dokumentet

184 185

3.116 K Logning af data om sagen eller dokumentet

Det er et krav, at ændringer på sager og dokumenter indplaceret i registreringssystematikken kan logges og spores på henholdsvis sagen og dokumentet.

185** 665

3.117 K Hjælperegisterfunktionalitet til komplettering af registreringerne

Det er et krav, at Løsningen indeholder en hjælperegisterfunktionalitet til anvendelse ved den manuelle komplettering af registreringerne.

186 187

6.6 Organisation - forretningsobjektBegrebet ’organisation’ afspejler som forretningsobjekt den måde systemet opdeler Kunden i afdelinger, enheder, kontorer mv. Det er den udførende organisation, der skal beskrives i Løsningen. Forretningsobjektet kan også beskrive de myndigheder, som Kunden arbejder

Side 54 af 198

sammen med. Der findes således en instans af organisationsbegrebet, der er intern, og flere der er eksterne.

Løsningen skal kunne håndtere og rumme den interne myndighed (Kunden) samt relevante eksterne myndigheder (Ankenævnet, NPI) og interessenter. Derudover skal Løsningen på baggrund af organisationsbegrebet kunne etablere et eller flere generelle registrer, der kan benyttes til at tilknytte interne og eksterne aktører med relevant rolle ift. sag, dokument, aktivitet mv. Organisationsbegrebet rummer ud over mennesker og enheder (myndigheder, virksomheder, interne afdelinger mv.) også lokationer.Organisationsstrukturen i Løsningen skal kunne arves fra det system som Kunden vedligeholder organisationsstrukturen i (Microsoft Active Directory).

Organisation – forretningsobjekt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.118 K Organisation – håndtering af både intern og ekstern organisation

Det er et krav, at Løsningen kan spejle såvel den interne organisation som de eksterne aktører, der oprettes i Løsningen

187 188

3.119 K Organisation – brug af organisation ifm. sagsbehandling

Det er et krav, at såvel interne som eksterne personer og organisationer kan tilknyttes sagen med en specifik rolle.

188 189

3.120 K Organisation – oprettelse af enheder og personer

Det er et krav, at der kan oprettes såvel interne som eksterne enheder og personer i systemet og at personer kan indplaceres i en eller flere relevante enheder med anført rolle ift. myndigheden.

189 190

Side 55 af 198

Organisation – forretningsobjekt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.121 K Organisation - tildeling af ansvar for opgave til intern organisatorisk enhed

Det er et krav, at Løsningen giver mulighed for at tildele en intern organisatorisk enhed ansvar for en specifik opgave eller for sagen og dokumenter generelt.

190 191

3.122 K Organisation – enheder og adresser fra registret til sag

Det er et krav, at Løsningen understøtter sammenhæng mellem organisationsstrukturen og sagsbehandlingen. Fx at adresser, telefonnumre og andre kontaktdata nedarves til underordnet enhed og person i forbindelse med brevflet mv, hvis der ikke er påført specifik adresse på underordnet enhed/person.

191** 615

3.123 K Organisation – spejling og dynamisk brug af myndighedens brugerstyring

Det er et krav, at Løsningen kan spejle og gøre brug af Kundens generelle organisationsstruktur og brugerstyring i forbindelse med pålogning af brugere, sagsbehandling og vedligehold af organisationsstruktur fx skal en vilkårlig brug af brugerrettighedsstyring kunne benyttes i sagsbehandlingen.

192* 699

Side 56 af 198

7. Arbejdsopgaver Løsningen skal understøtte

7.1 DelarbejdsgangeI dette afsnit beskrives de behov, som Løsningen effektivt skal understøtte ved hjælp af basisfunktionalitet. Basisfunktionaliteten er i dette afsnit beskrevet ved hjælp af en række delarbejdsgange. Formålet med at beskrive behovene på delarbejdsgangsniveau er at tydeliggøre de forskellige situationer som Løsningen skal understøtte. Den enkelte delarbejdsgang er indledningsvis beskrevet i forhold til, hvad den indeholder og hvad der evt. er særligt vigtigt for brugeren, når delarbejdsgangen udføres.Hver delarbejdsgang indeholder en kort beskrivelse af delarbejdsgangens start- og sluttilstand. Start- og sluttilstand beskriver på et overordnet niveau, hvilken tilstand delarbejdsgangen er i, når den startes op (forudsætninger for delarbejdsgangen) samt hvilken tilstand delarbejdsgangen kan forventes at være i, når den er afsluttet og eventuelt igangsætter en ny delarbejdsgang. Der vil imellem start- og sluttilstanden være en række aktiviteter, som er beskrevet som funktionelle krav, som Løsningen skal kunne understøtte. Start- og sluttilstand forholder sig således meget direkte til selve delarbejdsgangen.

Hvis en delarbejdsgang er beskrevet ved flere usecases, er der angivet en start- og sluttilstand for hver enkelt usecase.

Alle usecaeses er samlet i Underbilag 3.2

7.1.1 Opretter sag – delarbejdsgangSelvom Kunden har automatiseret oprettelsen af sager, kræver denne delarbejdsgang dog fortsat en del ressourcer. Det er af afgørende betydning for sagsbehandlernes arbejdssituation, at de metadata, der modtages eller dannes, med så høj grad af automatik som muligt, kan påføres sagen i forbindelse med sagsoprettelsen. Krav der relaterer sig til selve sagen, men ikke er direkte omfattet af delarbejdsgangen Opretter sag er at finde i afsnit 6.2, forretningsobjekt Sag.

Opretter sag

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.124 K Opretter sag – Opfyldelse af usecase Underbila 13* 700

Side 57 af 198

Opretter sag

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

Løsningen skal kunne understøtte aktøren, således at der kan oprettes sager som beskrevet i usecase ”Opretter Sag”.

g 3.2 Usecase ”01 Opretter sag”

3.125 K Beskrivelse af systemstøtte til sagsoprettelse

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”01 Opretter Sag”, opfyldes. Der ønskes en konkret skitsering af den arbejdsgang som aktøren involveres i på samme detailniveau som fremgår af eksemplet i usecasen.

Info. 4** 738

7.1.2 Behandler sag – delarbejdsgangDelarbejdsgangsskema

Delarbejdsgang Behandler sag

Omfattede aktører Bruger

Beskrivelse Delarbejdsgangen Behandler sag er her, hvor den formelle afgørelse træffes. I nogle tilfælde vil gennemførelsen af effektueringen foretages i et fagsystem. Derfor er det vigtige i behandlingen af en sag ofte, at der er en integration til fagsystemet (se afsnit 8.6 Integration). Delarbejdsgangen omfatter krav til typiske behov for funktionalitet undervejs i sagens behandling, dvs. simple workflows til fx intern høring af en sag/et dokument, advisfunktionalitet, projekt-/samlesager, udskrivning af sager, overdragelse af sagsansvaret til en anden sagsbehandler samt masseændring af sager. Øvrige centrale elementer for sagsbehandlingen er beskrevet i afsnit 7.3.4 om workflow og 8.2 om datamodel.

Starttilstand Sagen er oprettet.

Sluttilstand Sagen er afgjort og færdigbehandlet, og dermed klar til at blive afsluttet.

Side 58 af 198

Behandler sag

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.126 K Advis - advis (friststyring)Det er et krav, at brugeren skal kunne indsætte, rette og fjerne individuelle og organisatoriske adviser på sager og dokumenter - fx dato for, hvornår sagen forventes færdigbehandlet.

14 15

3.127 K Advis - tilknytning af abonnenterDet er et krav, at brugeren skal kunne vælge at tilknytte abonnementer til indsatte advis, så brugeren automatisk adviseres - fx via e-post eller Løsningen.

15 16

3.128g

K Advis - faste adviseringerDet er et krav, at der tilbydes faste adviseringer - fx ’dagens adviser’, ’ugens adviser’, ’månedens adviser’ etc. i relation til hhv. sagsbehandler og organisatorisk enhed.

16 17

3.129 K Advis - visning af advis i sags- og dokumentlisterDet er et krav, at advis skal kunne vises tydeligt i sags- og dokumentlister, så brugeren let kan overskue – fx om frister er overskredet.

17 18

3.130 K Udskrive sagDet er et krav, at det skal være enkelt at udskrive en sag – fx skal man kunne udskrive alle eller udvalgte af sagens dokumenter og journalnotater til en printer i én arbejdsgang.

18 19

3.131 K Udskrive sagsforklædeDet er et krav, at det skal være muligt at udskrive et sagsforklæde i form af udvalgte metadata fra sagen.

19 20

3.132 K Overdragelse - overdrager sagsansvarDet er et krav, at det skal være muligt at overdrage ansvaret for en sag fra én sagsbehandler til en anden.

20 21

Side 59 af 198

Behandler sag

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.133 K Overdragelse – overdrager rettigheder til anden sagsbehandlerDet er et krav, at rettigheder til ændringer af metadata på sagen og rettigheder til at tilgå dokumenter på sagen føres med, når sagsansvaret for en sag overføres til en anden sagsbehandler.

21 22

3.134 K Overdragelse - logning og visning af sagsoverdragelseshistorikDet er et krav, at sagsoverdragelse logges, så historik på sagsansvar let kan anskueliggøres.

22 23

3.135 K Intern processering og kvalitetssikring af dokumenter - understøttelse af enkle brugssituationerDet er et krav, at Løsningen tilbyder simple worksflows, der understøtter enkle brugssituationer, herunder en godkendelse og intern høring.

23 24

3.136 K Intern processering og kvalitetssikring af dokumenter - godkendelse af sag eller dokumentDet er et krav, at Løsningen tilbyder et simpelt workflow, hvor en sagsbehandler sender en sag eller et dokument til godkendelse hos en eller flere interne parter, der foretager godkendelsen. Godkendelsen returneres til sagsbehandleren og arkiveres på sagen som en selvstændig form for notering. Godkendelsesprocessen involverer sagsbehandleren og den eller dem, der skal godkende sagen eller dokumentet.

24 25

Side 60 af 198

Behandler sag

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.137 K Intern processering og kvalitetssikring af dokumenter - intern parallel høringDet er et krav, at Løsningen tilbyder et simpelt workflow, hvor en sagsbehandler sender en sag eller et dokument til en eller flere høringsparter, der samtidig kan udarbejde svar til sagsbehandleren. Svarene returneres til sagsbehandleren, når høringsparterne har behandlet høringsdokumentet. Svaret arkiveres automatisk på sagen som en selvstændig form for notering. Høringsprocessen involverer sagsbehandleren og en eller flere høringsparter.

25 26

3.138 K Intern processering og kvalitetssikring af dokumenter - intern seriel høringDet er et krav, at Løsningen understøtter simpelt workflow, hvor en sagsbehandler sender en sag eller et dokument til en række af høringsparter. Den første i rækken udfærdiger svar og videresender til næste part i rækken, der slutteligt returnerer de samlede kommentarer til sagsbehandleren. Høringsprocessen involverer sagsbehandleren og en eller flere høringsparter

26 27

3.139 K Intern processering og kvalitetssikring af dokumenter - opmærkning og låsning af dokumentversionDet et krav, at Løsningen i forbindelse med en godkendelse eller høring kan sættes op til automatisk at opmærke og låse dokumentversionen som godkendt eller været i høring.

27 28

3.140 K Intern processering og kvalitetssikring af dokumenter - registrering af de enkelte trinDet er et krav, at de enkelte trin i de simple workflows registreres i sagsprocessen, så det er muligt og enkelt at se, hvilket trin i processen, der aktuelt er aktivt, og hvornår og af hvem de enkelte trin skal udføres/er udført af.

28 29

Side 61 af 198

Behandler sag

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.141 K Intern processering og kvalitetssikring af dokumenter - dokumentation af sagsprocessenDet er et krav, at den dokumenterede sagsproces er tilgængelig for sagsbehandleren, både hvad angår aktive og historiske workflows.

29 30

3.142 K Intern processering og kvalitetssikring af dokumenter - rolle og rettighedsstyring

Det er et krav, at det er muligt at arbejde med roller eller rettigheder til de simple workflows, således at det fx kan specificeres, hvem der har mulighed for og/eller har pligt til godkende/beslutte sagens videregivelse til næste trin

30 31

7.1.3 Afslutter sag – delarbejdsgangAfslutning af en sag har ofte betydning for en række efterfølgende opgaver. Eksempelvis er der - i relation til afslutning af en sag - behov for statistiske udtræk og en systemunderstøttelse af opgaverne arkivering, aflevering og i enkeltstående tilfælde senere kassation af sager og dokumenter. I relation til afslutningen af sagen, skal det fx være muligt, at Løsningen prompter brugeren for relevante sagsafslutningsspecifikke oplysninger af statistik- og afleveringsmæssig betydning. Eksempelvis skal det være muligt at placere obligatoriske metadataopmærkninger i forbindelse med sagsafslutningen, hvis de først er mulige/relevante at udfylde ved sagens afslutning.

Afslutter sag

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.143 K Afslutter sag – Opfyldelse af usecase

Løsningen skal kunne understøtte aktøren, således at der kan afsluttes sager som beskrevet i usecase ”02 Afslutter Sag”.

Underbilag 3.2 Usecase ”02 Afslutter

31* 701

Side 62 af 198

Afslutter sag

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

sag”

3.144 K Beskrivelse af systemstøtte til sagsafslutning

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”02 Afslutter Sag” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 5** 739

7.1.4 Tilknytter Interessent – delarbejdsgang Det at tilknytte eller oprette en Interessent er en ofte udført opgave, der med fordel kan effektiviseres. Løsningen skal derfor sikre:- at registreringsprocessen i forbindelse med tilknytning af interessentinformation ligger så tæt på brugeren som muligt.- at interessentinformationen ved nye tilknytninger altid er opdateret, også selvom den ligger internt, dvs. at interessentinformationen ligger i et interessentregister som en del af Løsningen.- at tilknytningen mellem interessenter og sager/dokumenter mv. sker ensartet uanset om interessenten er kendt af Løsningen eller ej- at interessentinformation i genkendeligt format (fx fra en e-post eller fra en Følgeseddel mv.) benyttes til automatisk registrering af alle relevante oplysninger på interessenten.- at en kendt/benyttet interessent oprettes i internt register i forbindelse med den første tilknytning til en sag/et dokument mv.

Side 63 af 198

Tilknytter interessent

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.145 K Tilknytter interessent – opfyldelse af usecase

Løsningen skal kunne understøtte aktøren, således at der kan tilknyttes en interessent til sagen som beskrevet i usecase ”03 Tilknytter interessent”.

Underbilag 3.2 Usecase ”03 Tilknytter interessent”

32** 708

3.146 K Beskrivelse af systemstøtte til tilknytning af interessent

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”03 Tilknytter interessent” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 6* 740

3.147 K Tilknytning af interessent via decentralt interessentregister

Det er et krav, at Løsningen kan integrere til et decentralt register, hvis myndigheden ønsker at gøre brug af et sådant.

33** 673

3.148 K Let adgang til sagens interessenter ved tilknytning af interessent på dokumenter, aktiviteter mv.

Det er et krav, at sagsbehandleren let kan få overblik over og tilknytte interessenter fra sagen til dokumenter, aktiviteter mv.

34* 709

3.149 K Oprettelse af interessent, som ikke er kendt i andre registre

Det er et krav, at det er muligt at tilknytte (og dermed oprette) en interessent på sagen, som hverken er oprettet eller kendt i nogle registre, såvel eksterne som interne, i forvejen.

35** 702

Side 64 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.150 K Automatisk overførsel af interessent-informationer tilgået Kunden pr. e-post

Det er et krav, at den interessentinformation, der tilgår Kunden per e-post, automatisk overføres til søge- og registreringsbilleder ifm. journaliseringen af indgående e-post. Hvis der er tale om et sagsinitierende dokument skal informationen kunne overføres til Tilknyt-interessent søgebilledet nævnt i usecase ”03 Tilknytter interessent”.

Se usecase i Underbilag 3.2.

36** 595

3.151 K Automatisk overførsel/brug af interessentinformationer tilgået Kunden pr. Følgeseddel

Det er et krav, at Løsningen kan understøtte, at den interessentinformation, der tilgår Kunden pr. Følgeseddel, automatisk overføres ifm. journaliseringen af dokumenter, der følger med følgesedlen. Hvis følgesedlen følger et sagsinitierende dokument, skal interessentinformationen kunne overføres til Tilknyt-interessent søgebilledet nævnt i usecase ”03 Tilknytter interessent”.

Se usecase i Underbilag 3.2.

37** 596

3.152 K Synkronisering af Løsningens interessentregister op imod andre registre

Det er et krav, at Løsningen understøtter, at der i forbindelse med løbende opdatering af et centralt/decentralt personregister kan ske en synkronisering af de interessenter i Løsningens register, som er hentet fra det centrale/decentrale personregister.

38** 710

Side 65 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.153 K Mulighed for synkronisering af virksomheder mv. i interessentregister

Det er et krav, at Løsningen kan understøtte, at det er muligt at få masseopdateret alle de virksomheder i Kundens interessentregister, der er indhentet via opslag i det centrale virksomhedsregister iht. scenarium beskrevet i usecase ”03 Tilknytter interessent”.

Se Usecase i Underbilag 3.2.

39** 597

3.154 K Fastholdelse af interessenthistorik på tidligere og eksisterende sager

Det er et krav, at Løsningen kan fastholde interessenthistorik og opdateret information på tidligere og eksisterende sager til brug for interessenttilknytning på nye sager.

40* 711

3.155 K Beskrivelse af funktionalitet til synkronisering af interessentregister

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.152 – 3.154

Info. 7* 741

7.1.5 Modtager og placerer post – delarbejdsgangAt modtage og placere post dækker de aktiviteter, der er forbundet med håndtering af information og dokumenter, såvel i papirform som digitalt, fra de modtages hos Kunden til de er korrekt registreret i Løsningen. Denne arbejdsgang ligger således i forlængelse af skanningsprocessen. Begrebet post dækker al ”henvendelse” til Kunden fra omverdenen samt overdragelser og henvendelser internt. Henvendelsen kan ske via e-post, papirbaseret post, internt i Løsningen, fra eksternt system eller fra portal eller hjemmeside. For at gøre posthåndteringen mere ensartet for Kunden, skal Løsningens postkasse kunne håndtere al indgående post på en for brugerne ensartet måde, uanset om det er digitaliseret via skanning eller modtaget digitalt.Hvis det skal være muligt for ESDH-postkassen, at håndtere post ensartet, kræver det, at de forskellige kilder til modtagelse kan levere posten i et for ESDH-postkassen kendt format. For at målrette og konkretisere opgaven med ESDH-postkassen bruges FESD-standarder for digitale

Side 66 af 198

følgesedler, som fælles og kendte formater. Det vil sige, som de formater ESDH-postkassen skal kunne håndtere og som kildesystemer og services skal kunne levere data i.

Datafølgeseddel

Muligheden for at automatisere og effektivisere processerne relateret til dataudveksling og ensartet håndtering af indgående post hænger tæt sammen med mere konkret implementering af følgesedlen i Løsningen. Begrebet Følgeseddel i denne kravspecifikation henviser til FESD-standarden for Datafølgeseddel, som er FESD- og FESD-kompatible systemers udvekslingsformat for sagsrelaterede dokumenter inklusiv metadata på sags- og dokumentniveau (om sagen, dokumentet, interessenter og afsendere/modtagere). Datafølgeseddel kan overdrage en komplet sag inklusiv dokumenter og interessentinformationer

Her bruges begrebet Følgeseddel som dækkende for Datafølgeseddel.

Konkret implementering af Følgeseddel-logik

Da Løsningen som grundvilkår skal kunne gribe og aflevere sager og dokumenter i Følgeseddel-format, er det oplagt at gøre følgesedlen til ’transportformatet’ mellem Kunden og omverdenen – dækkende andre myndigheder, borgere og øvrige interessenter.Følgesedlen skal benyttes til at sikre overdragelse, afsendelse og modtagelse af data og dokumenter på en ensartet måde. Denne sikring opnås ved at etablere funktionslogik i Løsningen, der gør brug af Følgesedlen som det udvekslingsformat håndtering af indgående og udgående post baseres på. ESDH-postkassen, som den er kaldt i kravspecifikationen, ønskes bearbejdet således, at den understøtter ensartet modtagelse og registrering af indgående post uafhængigt af forsendelsesform.Det betyder, at Leverandøren skal tænke Følgesedlen ind i de forskellige kanaler til modtagelse og afsendelse af post. Eksempelvis er det ikke nok, at skanningsløsningen kan dirigere traditionel og digitaliseret post ind i Løsningen. Det samme skal e-postløsning kunne, således at elektronisk post, der ikke umiddelbart kan journaliseres af den modtagne part, kan dirigeres ind i Løsningen, således, at det bliver omfattet af en ensartet procedure for modtagelse og fordeling af journalpligtig post. For Leverandøren skal fokus være på konkret implementering af standarden i Løsningen. Løsningen skal kunne gribe og omforme til og fra Følgesedlen, som en integreret del af de processer, der har med afsendelse og modtagelse at gøre.Udover de tilhørende usecases er der stillet konkrete krav til ESDH-postkassen og til funktionalitet til præjournalisering og integration mellem E-post systemet og Løsningen.

Præjournalisering

Side 67 af 198

Formålet med en præjournaliseringsfunktion, der kan arbejde med Følgeseddel, er at skabe en fælles indgang til Løsningen. Derudover skal præjournaliseringen sikre, at al kendt information kan genbruges og automatisk overføres ifm. journalisering af dokumenter, samt at dokumenter kan beriges med metadata i kendt og ønsket omfang, hvor det måtte være relevant og muligt. Da Følgesedlen kan variere i størrelse og indhold – fra ét dokument til en større mængde sagsdata og dokumenter - er det vigtigt, at brugergrænsefladen på Præjournaliseringsfunktionen kan varieres, således at den kan målrettes den konkrete opgave. Den skal fx kunne rumme og præsentere en hel sag med metadata på både sag og journalpost samt flere dokumenter og interessenter/roller på både sags- og dokument-niveau. I andre tilfælde skal den blot give mulighed for begrænset metadataberigelse på et enkelt dokument og overførsel til ESDH-postkassen.

Modtager og placerer post

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.156 K Modtager og fordeler post sendt i standardiseret format – Opfyldelse af usecase

Løsningen skal kunne understøtte, at der kan modtages og placeres indgående post som beskrevet i følgende usecase: ”04 Modtager og fordeler post sendt i standardiseret format”.

Underbilag 3.2 Usecase ”04 Modtager og fordeler post sendt i standardiseret format

41** 42

3.157 K Beskrivelse af funktionalitet og brugerflade til understøttelse af Modtagelse og fordeling af post i standardiseret format

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”04 Modtager og fordeler post sendt i standardiseret format” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 8** 742

Side 68 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.158 K Modtagelse og standardisering/journalisering af ikke-standardiseret post – Opfyldelse af usecase

Det er et krav, at Løsningen understøtter, at der kan modtages og placeres indgående post som beskrevet i følgende usecase: ”05 Modtager og standardiserer/journaliserer ikke-standardiseret post.

Underbilag 3.2 Usecase”05 Modtager og standardiserer/journaliserer ikke-standardiseret post

42** 43

3.159 K Beskrivelse af funktionalitet og brugerflade til Modtagelse og placering af ikke-standardiseret post

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”05 Modtager og standardiserer/journaliserer ikke-standardiseret post opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detail niveau, som fremgår af eksemplet i usecasen.

Info. 9** 743

Side 69 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.160 K Præjournalisering - lagring og registrering af modtaget e-post i Løsningen

Det er et krav, at Løsningen tilbyder en præjournaliseringsfunktion, der så vidt muligt sikrer fleksibilitet og automatisering i modtagelses- og placeringsprocessen. I præjournaliseringen skal Løsningen fx understøtte:• automatisk overførsel af relevante informationer fra e-post til registreringsfelter• hurtigt overblik over/adgang til alle obligatoriske felter• mulighed for at redigere og tilføje metadataværdier på både e-post (hoveddokument) og vedhæftede dokumenter (bilag)• mulighed for at påføre ansvarlig enhed og sagsbehandler for e-posten• mulighed for direkte overførsel af præjournaliseringen (i følgeseddelformat) og e-posten til ESDH-postkassen

43 44

3.161 K Præjournalisering – følgeseddel som grundlag

Det er et krav, at præjournaliseringsfunktionen er baseret på Følgesedlen, således at den kan arbejde på og viderelevere data i Følgeseddel-format.

44 45

3.162 K Præjournalisering – varierende brugerflade

Det er et krav, at præjournaliseringsfunktionen kan varieres med hensyn til brugerfladen, således at den er målrettet den konkrete sagsbehandlingsopgave.

45 46

Side 70 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.163 K Præjournalisering – genkendelighed i forhold til brugerflade

Det er et krav, at præjournaliseringsfunktionens varierende brugerflade så vidt muligt baseres på Løsningens standardfunktion til håndtering af lignende registrerings-/journaliseringsopgave.

46 47

3.164 K Præjournalisering – indhentning af standardværdier

Det er et krav, at funktionen uafhængigt af brugssituation kan sættes op, således at så mange metadata som muligt kan indhentes fra de modtagne dokumenter.

47 48

3.165 K Præjournalisering – håndtering af obligatoriske værdier

Det er et krav, at det for brugeren er synligt, hvilke felter, der er obligatoriske i forbindelse med journalisering af et dokument. Det skal til gengæld være muligt for brugeren, der kun har mulighed for at præregistre, at overføre dokumenter til ESDH-postkassen uden at udfylde alle obligatoriske felter. En evt. problemstilling kan evt. løses med midlertidige dummy-værdier i obligatoriske felter.

48 49

3.166 K Præjournalisering – opstart af funktion udenfor Løsningen

Det er et krav, at præjournaliseringsfunktionen kan aktiveres udenfor Løsningen. Det gælder både fra e-post systemet og fra andre systemer eller fil-drev mv., hvor brugerne ønsker at overføre dokumenter til Løsningen. Afhængigt af situationen skal dokumentet kunne færdigregistreres, præjournaliseres og/eller overføres til ESDH-postkassen

49 50

Side 71 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.167 K Præjournalisering – adgang til opgaveklassifikation

Det skal i forbindelse med præjournalisering være muligt at gøre brug af Kundens journal-/emneplan og prædefinerede sagstyper.

50** 598

3.168 K Præjournalisering – overførsel til ESDH-postkassen

Det er et krav, at det i forbindelse med præjournaliseringen er muligt at overføre forsendelsen/posten til ESDH-postkassen for en valgt enhed og/eller sagsbehandler.

51 52

3.169 K Beskrivelse af præjournaliseringsfunktion

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav til præjournalisering (krav 3.160 - 3.168)

Info. 10* 744

3.170 K ESDH-postkassen - understøttelse og facilitering af postmodtagelse

Det er et krav, at Løsningen stiller en systempostkasse til rådighed, der indeholder faciliteter til modtagelse og placering af alle former for digitaliseret dokumentation, uanset om dokumenterne tilgår Kunden i papirform eller digitalt. Eksempler på relevant funktionalitet er:• vis dokument(er) i forsendelse• vis/rediger oplysninger om forsendelsen• fordel post til anden enhed/sagsbehandler• opret dokument(er) pba. forsendelse• opret sag på baggrund af forsendelse

52* 674

Side 72 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.171 K ESDH-postkassen - rollestyret adgang til fordelingsfunktioner

Det er et krav, at Løsningen kan begrænse adgangen til ESDH-postkassens fordelingsfunktioner baseret på fx brugerrolle.

53 54

3.172 K ESDH-postkassen - håndtering af al digitaliseret post

Det er et krav, at ESDH-postkassen kan håndtere alle dokumenter/digitaliseret post som dirigeres til postkassen. Det gælder både:• e-post, fx fra central mailboks• skannet papirpost• følgesedler• dokumenter modtaget fra Portal/hjemmeside• dokumenter overført fra fildrev mv.• sager og/eller dokumenter overført via system-til-systemintegration

54 55

3.173 K Beskrivelse af ESDH-/systempostkasse-funktion

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav til ESDH-postkassen (krav 3.170 – 3.172).

Info. 11* 745

Side 73 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.174 K E-post - lagring og registrering af modtaget e-post i Løsningen

Det er et krav, at Løsningen kan integreres med Kundens e-postsystem, således at den enkelte bruger kan lagre og registrere modtaget e-post i Løsningen. I registreringen skal Løsningen fx understøtte:• overførsel af relevante informationer fra e-post til søge- og registreringsfelter• hurtig adgang til registrering på alle obligatoriske felter• let adgang til sager med e-post afsender som interessent• let fremsøgning af eksisterende sag samt adgang til oprettelse af ny sag• mulighed for at registrere vedhæftede dokumenter som selvstændige dokumenter• håndtering af digital signatur/sikker e-post forklæde (fx via logning i forbindelse med udpakning)

55* 683

3.175 K E-post - muligheder for lagring af filer, der er vedhæftet en e-post

Det er et krav, at brugeren selv skal kunne vælge, hvorvidt filer, der er vedhæftet en e postmeddelelse, skal lagres på samme måde som de er modtaget, altså som vedhæftede filer til en e-postmeddelelse, eller som selvstændige dokumenter. Brugeren skal ligeledes kunne vælge, hvilke af de vedhæftede filer, der skal lagres sammen med e-posten

56 57

Side 74 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.176 MK E-post - håndtering af e-post forsynet med digital signatur

Det er et krav, at Løsningen skal kunne håndtere e-post meddelelser forsynet med digital signatur. Den originale digitale signatur skal af bevismæssige grunde enten kunne lagres i Løsningen sammen med meddelelsen, eller den digitale signatur skal fjernes fra meddelelsen efter, at der er foretaget en undersøgelse af signaturens gyldighed, og resultatet af undersøgelsen skal lagres sammen med meddelelsen.

Krav til brugen og lagringen af digital signatur findes i afsnit 8.7 Brugerstyring og sikkerhed.

57* 813

3.177 K E-post - automatisk generering af oplysninger pba. e-post systemet

Det er et krav, at Løsningen automatisk genererer oplysninger om fx dokumenttitel, tidspunkt og dokumenttype på grundlag af oplysninger hentet fra e-post systemet, når brugeren har modtaget en e-post.

58 59

3.178 K E-post - håndtering af e-post forsynet med Følgeseddel

Det er et krav, at Løsningen skal kunne håndtere e-post forsynet med Følgeseddel. Løsningen skal kunne anvende de fra Følgesedlen medsendte metadata i forbindelse med registrering af e-posten i Løsningen

59 60

3.179 K Beskrivelse af funktionalitet til registrering af e-post med digital signatur og Følgeseddel

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.174 – 3.178.

Info. 12* 746

Side 75 af 198

7.1.6 Danner og afsender post – delarbejdsgangNår post afsendes og modtages myndigheder imellem, er der krav til kommunikationsformen iht. eDag 2 mv. Når post sendes til borgere eller andre private interessenter, kan kommunikationsformen variere afhængigt af hvilken kommunikationsform borgeren ønsker og har givet tilsagn til.Den ønskede udvikling er, at en stadig større del af kommunikationen myndigheder imellem og med borgerne bliver digital, sikker og ensartet, uden at det stiller krav til borgerens kontor- eller e-post løsning. Sikker e-post og digital signering er centrale systemelementer, når vi taler kommunikation myndighederne imellem. I relation til borgere og øvrige interessenter, er det sværere at stille krav til brug af standarder og elementer som digital signering og sikker e-post. Kommunikationsvejene til borgerne skal gerne have samme grad af sikkerhed men være format- og teknologiuafhængige.Såvel teknologi- og formatuafhængighed, som høj grad af sikkerhed kan nås ved brug af fx NemID og e-boks, der er tiltænkt en central rolle, i den fremtidige kommunikation mellem myndigheder og borgere. Hvis en borger giver tilsagn om kommunikation via dokumentboks skal dannelse og afsendelse af dokumenter kunne ske via pakning af post i et vedtaget format for publiceringen til dokumentboks. Dokumentboksen sikrer både formatuafhængighed - ved at stille ’Læs/svar/vedhæft’-funktionalitet til rådighed på portalen - og sikkerhed ved at gøre brug af NemID ifm. pålogning.Løsningen skal derfor understøtte e-post uafhængig publicering og advisering samt automatiseret og differentieret dannelse og distribution af dokumenter.

Danner og afsender post

Krav

Kravtype

Krav Reference FESD2 ref.

PVS ID

3.180 K Danner og afsender post til én modtager – opfyldelse af usecase

Det er et krav, at Løsningen kan understøtte aktøren, således at der kan dannes og afsendes post som beskrevet i følgende usecase ”06 Danner og afsender post til én modtager”.

Underbilag 3.2 Usecase ”06 Danner og afsender post til én modtager”

60 61

Side 76 af 198


Krav

Kravtype


PVS ID

3.181 K Beskrivelse af systemstøtte til dannelse og afsendelse af post til én modtager

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”06 Danner og afsender post til én modtager” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 13**

747

3.182 K Automatisk låsning samt konvertering af dokumenter ved afsendelse

Det skal være muligt at definere, hvilke typer af korrespondance, der ved afsendelse automatisk skal låses og konverteres til ikke-redigerbare dokumentformater.

- 586

3.183 K Danner og afsender post til flere modtagere – Opfyldelse af usecase

Det er et krav, at Løsningen kan understøtte aktøren, således at der kan dannes og afsendes post som beskrevet i følgende usecase: ”07 Danner og afsender post til flere modtagere”.

Underbilag 3.2 Usecase ”07 Danner og afsender post til flere modtagere”

61 62

3.184 K Beskrivelse af systemstøtte til dannelse og afsendelse af post til flere modtagere

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”07 Danner og afsender post til flere modtagere” opfyldes. Der ønskes en konkret beskrivelse af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 14**

748

Side 77 af 198


Krav

Kravtype


PVS ID

3.185 K Faciliteter til afsendelse

Det er et krav, at Løsningen understøtter Kundens postafsendelse og indeholder faciliteter til afsendelse af post såvel i papirform som digitalt.

62* 675

3.186 MK Konvertering af formater

Det er et krav, at Løsningen indeholder konverteringsfaciliteter, der kan konvertere de formater, som dokumenterne forefindes i, til fastlagte gængse fil- og dokumentformater. Fx fra MS Word til Pdf.

63 64

3.187 K Indhentning af oplysninger om modtager

Det er et krav, at brugeren kan hente relevante oplysninger (fx navn og adresse) om modtageren/modtagerne af forsendelser fra et interessentregister i forbindelse med dannelse og afsendelse af post.

Krav til interessentregister og interessenttilknytning er nærmere beskrevet under afsnit 7.1.4, Tilknytter interessent.

64** 634

3.188 K E-post - lagring af e-post som del af afsendelse

Det er et krav, at Løsningen kan integreres med Kundens e-post system, således at den enkelte bruger kan lagre afsendt e-post i Løsningen i forbindelse med postafsendelsen.

65* 684

3.189 K E-post - afsendelse af sag via E-post med Følgeseddel

Det er et krav, at der er mulighed for let adgang til at sende en sag via e-post, herunder en følgeseddel med metadata om sagen, sagens dokumenter og notater

66 67

Side 78 af 198


Krav

Kravtype


PVS ID

3.190 K E-post - lagring af vedhæftede filer

Det er et krav, at filer, der er vedhæftet en e-post, skal kunne sendes i det originale tekniske format, og skal lagres som bilag til e-postmeddelelsen i det samme tekniske format. Det skal dog være muligt for systemet i forbindelse med den endelige arkivering at afvise filer i formater, som Kunden ikke vil bevare eller er vanskelige at konvertere.

Krav til konvertering er nærmere beskrevet under afsnit 7.1.9 Afleverer til offentligt arkiv.

67* 676

3.191 K E-post - initiering af e-post forsendelse fra flere systemer

Det er et krav, at e-post forsendelse af dokumenter skal kunne initieres fra såvel Løsningen, som fra kontorprogrammer (fx tekstbehandling) og - post system.

68 69

3.192 K E-post – vedhæftning og afsendelse af flere dokumenter

Det er et krav, at e-post baseret forsendelse initieret i Løsningen eller e-postsystemet understøtter vedhæftning og afsendelse af flere dokumenter i samme arbejdsgang.

69 70

3.193 K E-post - dannelse af Følgeseddel med metadata ifm. dannelse af e-post

Det er et krav, at Løsningen kan danne en Følgeseddel, der indeholder de sendte dokumenters metadata i forbindelse med dannelse af e-posten.

70 71

3.194 K E-post - tilknytning af Følgeseddel til e-post

Det er et krav, at brugeren kan vælge at medsende en Følgeseddel i forbindelse med afsendelse af dokument via e-post.

71 72

Side 79 af 198


Krav

Kravtype


PVS ID

3.195 K E-post - beskrivelse af funktionalitet til håndtering af e-post med Følgeseddel mv.

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.188 – 3.194. Beskrivelsen skal omfatte, hvorledes dette gøres for hvert af de e-post systemer, som Løsningen integrerer med.

Info. 15*

749

3.196 K Dannelse af post ved fletning og brug af skabelon

Det er et krav, at Løsningen understøtter tæt integration til tekstbehandlingssystemet, som muliggør dannelse af post med fletning af postmodtagere og postafsender via dokumentskabeloner.

Se afsnit 7.1.7, Opretter og behandler dokument.

72* 814

3.197 K Dannelse af enslydende breve til flere modtagere

Det er et krav, at Løsningen understøtter dannelse af flere dokumenter i samme arbejdsgang, hvis enslydende dokument skal sendes til flere postmodtage-re/adressater.

73 74

3.198 K Dannelse af forskellige breve til flere modtagere

Det er et krav, at Løsningen understøtter dannelse af forskellige prædefinerede dokumenter/breve som led i samme arbejdsgang, hvor forskellige dokumenter/breve skal sendes til flere fast definerede modtagere som led i et standardiseret sagsbehandlingsforløb.

74 75

Side 80 af 198


Krav

Kravtype


PVS ID

3.199 K Masseudsendelse af standardbreve via e-post

Det er et krav, at Løsningen understøtter masseudsendelse af e-mails. Der tænkes fx på en situation, hvor et antal modtagere flettes med en standard brev-skabelon, hvorefter et personligt ’brev’ (evt. i pdf-format) vedhæftes som fil i hver sin sikre e-post.

75 76

3.200 MK Automatiseret udsendelse af breve via forskellige kanaler

Det er et krav, at Løsningen kan benytte indstillinger på den enkelte sagsdeltager til at automatisere dannelse og udsendelse af post i den forsendelsesform, som modtageren har ønsket. Forsendelsesformen skal samtidig kunne være styrende for formatet for det afsendte (om det udskrives som en almindelig tekstfil, konverteres til en pdf-fil der vedhæftes en e-post eller sendes som Følgeseddel mv.)

76 77

3.201 K Beskrivelse af funktionalitet til massedannelse og afsendelse


Info. 16*

750

7.1.7 Opretter og behandler dokument - delarbejdsgangDer er behov for at kunne oprette og behandle dokumenter på en nem og intuitiv måde. Delarbejdsgangen Opretter og behandler dokument omhandler dokumentproduktion og registrering af metadata. Delarbejdsgangen beskriver egenproduktion af dokumenter og vedrører krav til integration til kontorautomatiseringsprogrammer. Her er fokus på tekstbehandling i forbindelse med produktion af dokumenters indhold (dokumentproduktion), og beskrivelsen omfatter oprettelse af dokumenter i Løsningen, tilknytning til sager/andre

Side 81 af 198

dokumenter/dokumentinteressenter, registrering af dokumenters metadata, samt anvendelse af skabeloner og fraser.

Opretter og behandler dokument

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.202 K Opretter og behandler dokument – Opfyldelse af usecase

Det er et krav, at Løsningen kan understøtte aktøren, således at der kan oprettes og behandles dokumenter som beskrevet i usecase ”08 Opretter og behandler dokument”.

Underbilag 3.2 Usecase ”08 Opretter og behandler dokument”

77 78

3.203 K Beskrivelse af systemstøtte til oprettelse og behandling af dokumenter

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”08 Opretter og behandler dokument” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 17**

751

3.204 MK Integration med MS Office

Det er et krav, at Løsningen skal være tæt integreret med MS Office pakken (primært Word, Excel, Outlook og PowerPoint). Det betyder blandt andet, at det skal være muligt at journalisere dokumenter i Løsningen direkte fra MS Office programmerne. Generelt skal Løsningen stille et interface til rådighed, således at det er muligt at åbne, redigere og gemme MS Office dokumenter, der er dannet af systemer uden for Løsningen.

- 455

Side 82 af 198

Opretter og behandler dokument

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.205 K Brugervenlig oprettelse af fraser og ændringer af disse i frasebibliotek

Løsningen skal gøre det muligt for udvalgte brugere at oprette og redigere fraser i et frasebibliotek på en brugervenlig måde.

- 523

3.206 K Dokumentation af brugervenlig oprettelse af fraser og ændringer af disse i frasebibiliotek

Leverandøren bedes demonstrere brugervenligheden af funktionaliteten beskrevet i krav 3.205 f.eks. vha. skærmdumps.

- 752

7.1.8 Udveksler sager og dokumenter - delarbejdsgangDet kan være meget omstændeligt, omkostningstungt og ressourcekrævende at overdrage sager fra en myndighed til en anden, f.eks. fra Kunden til departementet eller andre myndigheder, hvor udlevering af sagens akter i dag er papirbaseret Kunden ønsker en høj grad af systemunderstøttelse til udveksling af sager og dokumenter.

Udveksler sager og dokumenter

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.207 K Overdragelse af sagsportefølje – Opfyldelse af usecase

Det er et krav, at Løsningen kan understøtte aktøren, således at der kan overdrages en sagsportefølje fra en myndighed til en anden som beskrevet i følgende usecase ”09 Overdrager sagsportefølje”.

Underbilag 3.2 Usecase ”09 Overdrager sagsportefølje”

78 79

3.208 K Beskrivelse af systemstøtte overdragelse af sagsportefølje

Leverandøren skal beskrive, hvorledes behovet som er skitseret i usecase ”09 Overdrager

Info. 18**

753

Side 83 af 198

Udveksler sager og dokumenter

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

sagsportefølje” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

3.209 K Overdragelse af enkeltsag – Opfyldelse af usecase

Det er et krav, at Løsningen kan understøtte aktøren, således at der kan overdrages enkelte sager fra en myndighed til en anden som beskrevet i følgende usecase ”10 Overdrager enkeltsag”.

Underbilag 3.2 Usecase ”10 Overdrager enkeltsag”

79 80

3.210 K Beskrivelse af systemstøtte overdragelse af enkeltsag

Leverandøren skal beskrive, hvorledes behovet som er skitseret i usecase ”10 Overdrager enkeltsag” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 19**

754

7.1.9 Afleverer til offentligt arkiv – delarbejdsgang Aflevering til offentligt arkiv er en opgave, der udføres sjældent, men når den udføres er det en meget ressourcetung opgave. Der bruges meget tid på at eksportere data og konvertere dokumenter til, det af Statens Arkiver fastsatte, afleveringsformat. Der er et ønske om, at selve udsøgningen og konverteringen af dokumenter kan automatiseres og ske løbende på baggrund af en systemopsætning. Dette kan eksempelvis ske via natlige tidssatte systemhandlinger/batch-kørsler, hvor der foretages en tiff-konvertering iht. den systeminstruks, der er aftalt med Statens Arkiver. Det er i Kundens interesse, at afleveringen kan ske så billigt og hensigtsmæssigt som muligt, hvilket betyder, at Løsningen skal kunne forberedes og opsættes i henhold til Kundens behov, retningslinjer og aftaler på et så tidligt tidspunkt, som muligt.

Side 84 af 198

Side 85 af 198

Delarbejdsgang – skema

Delarbejdsgang Afleverer til offentligt arkiv

Omfattede brugertyper Bruger

Beskrivelse Fælles for alle offentlige myndigheder er, at de er underlagt arkivloven, hvilket betyder, at de skal aflevere bevaringsværdige digitale arkivalier i henhold til de af Statens arkiver fastsatte regler herfor. Kundens Løsning skal anmeldes og godkendes af Statens Arkiver.Overordnet rummer delarbejdsgangen:

1. krav, der relaterer sig til selve afleveringen,2. krav, der er relevante i forhold til systemets bidrag til

automatisering af delarbejdsgangen, herundera. udsøgning/samling af de relevante sager og

dokumenter,b. konvertering af dokumenter til det af Statens

arkiver besluttede format,c. udarbejdelse af en arkiveringsversion, godkendelse

af aflevering,d. stempling/anvisning af afleveret status på

afleverede sager og dokumenter samt kassation/sletning af sager.

3. krav til den systemmæssige opsætningStarttilstand Starttilstanden er knyttet til systemopsætningen og igangsættes af,

at der foreligger aftale om, hvilke data om sager og dokumenter, der skal afleveres.Starttilstanden ift. selve afleveringen er, at arkivperioden er overstået, og at det modtagende arkiv har udarbejdet en afleveringsbestemmelse, således at afleveringsversionen kan genereres iht. Bekendtgørelse nr. 1007 af 20. august 2010 om arkiveringsversioner fra Statens Arkiver.

Sluttilstand Sluttilstanden er, at afleveringen er gennemført og godkendt af det modtagende arkiv. Registreringsdelen for den gamle arkiv periode er lukket for yderligere registreringer.

Afleverer til offentligt arkiv

Krav

Kravtype


PVS ID

3.211 MK Efterlevelse af krav til elektronisk aflevering

Det er et krav, at Løsningen kan leve op til offentlige arkivers regler indenfor elektronisk aflevering iht. de, til enhver tid af, Statens arkiver, fastsatte regler. I forhold til aflevering til Statens Arkiver gælder det, at den efterspurgte løsning til en hver tid skal leve op til bestemmelserne i Arkivloven og tilhørende cirkulærer og bekendtgørelser mv.

Pt. findes reglerne i bekendtgørelse nr 1035 af 21/08/2007 (Arkivloven)

80** 599

3.212 K Beskrivelse af Løsningens efterlevelse af krav til elektronisk aflevering


Info. 20*

755

3.213 K Prøveaflevering til offentlige arkiver inden implementering

Det er et krav, at Leverandøren på anfordring fra Kunden kan dokumentere, at der kan produceres en prøveaflevering fra Løsningen, der omfangsmæssigt er repræsentativ, efter offentlige arkivers forskrifter. Dokumentationen kan enten være i form af en allerede afleveret arkivversion fra den løsning, der indgår i tilbuddet eller i form af dokumentation af, at der er foretaget en godkendt prøveaflevering af den version, der indgår i tilbuddet.

81* 677

3.214 K Godkendelse af prøveaflevering

Det er et krav, at prøveafleveringen kan godkendes i henhold til de offentlige arkivers forskrifter.

82* 692

Side 86 af 198


Krav

Kravtype


PVS ID

3.215 K Prøveafleveringer fra aktuel løsning

Det er et krav, at Leverandørens prøveaflevering tager udgangspunkt i og kan leveres fra den løsning, der indgår i tilbuddet.

83* 84

3.216z

K Systemunderstøttelsen af udsøgning af relevante sager og dokumenter

Det er et krav, at Løsningen i størst mulig omfang kan bidrage til automatisering af udsøgningen af relevante sager og dokumenter, der er knyttet til afleveringen til offentligt arkiv

84 85

3.217 K Opmærkning af dokumenter med dispensation for aflevering

Det er et krav, at Løsningen understøtter, at det skal være muligt at angive i afleveringsopsætningen, at der i enkelte tilfælde kan være dispensation til afleveringsfrihed, for enkelte dokumenttyper på baggrund af klassifikation eller dokumenttype mv.

85 86

3.218 MK Aflevering af dokumenter i arkiv-format

Det er et krav, at Kunden kan aflevere dokumenter i det af Statens Arkiver fastsatte og til enhver tid gældende afleveringsformat.

86* 678

3.219 MK Løbende konvertering til afleveringsformat

Det er et krav, at Løsningen i forbindelse med journalisering understøtter en forberedelse af afleveringsprocessen, herunder løbende konvertering til det til en hver tid gældende afleveringsformat.

87 88

Side 87 af 198


Krav

Kravtype


PVS ID

3.220 K Konvertering udenfor primær driftstid

Det er et krav, at Løsningen kan fortage konvertering, til det til enhver tid gældende afleveringsformat, udenfor primær driftstid.

For definition af primær driftstid se Bilag 6 Servicemål

88** 89

3.221 MK Eksport af relevante metadata

Det er et krav, at Løsningen kan understøtte eksport af relevante metadata relateret til de konverterede filer.

89 90

3.222 K Beskrivelse af funktionalitet til optimering af afleveringen


Info. 23*

758

3.223 K Angivelse af status på afleverede sager

Det er et krav, at Løsningen kan stemple/anvise ”afleveret” status på de sager og dokumenter.

90** 801

7.1.10 Danner sagsprocesoverblik – delarbejdsgang For at kunne synliggøre og måle på procesoptimeringer er det vigtigt, at Løsningen kan bidrage til at skabe sagsprocesoverblikket og bidrage med data og rapporter, der helt konkret kan dokumentere procesoptimering. Fx er der et ønske om, at Løsningen kan bidrage med en digital styringsreol, der på baggrund af fx et Lean-projekt kan være med til at styre og målrette sagsarbejdet og ressourceallokering mv. Udgangspunktet for delarbejdsgangen Danner sagsprocesoverblik er det sagsprocesoverblik, der dannes med udgangspunkt i Løsningens egne data. De øvrige scenarier er beskrevet i afsnit 7.3.4, Workflow funktionalitet og afsnit Error: Reference source not found

Side 88 af 198

Danner sagsprocesoverblik

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.224 K Overblik over proces- og fremdriftsstatus på den enkelte sag

Det er et krav, at Løsningen kan bidrage med et sagsoverblik på den enkelte sag. Overblikket skal tydeliggøre fremdriften på sagen i forhold til sammenlignelige sager og så vidt muligt anvise resterende opgaver/sagsproces.

194 195

3.225 K Digital styringsreol på enheds- og myndighedsniveau

Det er et krav, at Løsningen på baggrund af metadataangivelser på sagen kan skabe et sagsprocesoverblik på tværs af sagstyper, sagsfaser og enheder/afdelinger hos Kunden.

195* 621

3.226 K Beregning og visning af gennemløbstider for faser og sager på sagstyper

Det er et krav, at Løsningen på baggrund af logning af fase- og statusskift på sagen kan beregne og vise gennemsnitlige gennemløbstider for sager og sagsfaser fordelt på sagstyper.

196 197

3.227 K Dynamisk sagsprocesoverblik

Det er et krav, at sagsprocesoverblikket kan præsenteres som et dynamisk systemelement, fx en webpart, der opdateres løbende på baggrund af fx de seneste 1-3 måneders sagsbehandling.

197 198

Side 89 af 198

Delarbejdsgang Danner sagsprocesoverblik

Omfattede aktører Bruger

Beskrivelse Delarbejdsgangen Danner sagsprocesoverblik har fokus på understøttelse af de behov, der dels retter sig imod, at sagsbehandleren kan danne sig et overblik over, hvor den enkelte sag befinder sig i et forløb over tid, herunder end-to-end processer, der kun delvist håndteres af Løsningen. Dels at en leder på enheds- eller afdelingsniveau kan danne sig et overblik over, hvor mange af afdelingens/enhedens sager, der befinder sig i respektive faser af sagsprocessen.

Overblikket kræver i nogle tilfælde, at Løsningen samarbejder med andre systemer, herunder fagsystemer, økonomisystemet og services.

I andre tilfælde dannes sagsprocesoverblikket indenfor Løsningen ved dynamiske søgninger og visninger baseret på metadata på sagen.

Starttilstand Sagsprocesoverblikket genereres med udgangspunkt i Løsningen, hvor Løsningen benytter egne data og/eller information fra andre systemer.

Sluttilstand Løsningen har genereret et sagprocesoverblik på skærmen, der kan præsenteres, distribueres, afrapporteres, printes eller arbejdes videre med som datasæt i Løsningen, eller andet format/anden applikation.

Danner sagsprocesoverblik

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.228 K Tilgængelighed/distribution af sagsprocesoverblik

Det er et krav, at Løsningen kan understøtte, at sagsprocesoverblikket kan gøres tilgængeligt for relevante brugere. Fx som dynamisk webpart eller som regneark, præsentation mv. Enhedsleder og medarbejdere skal fx løbende kunne følge udviklingen mht. sagsgennemløbstider mv.

198 199

3.229 K Print af sagsprocesoverblik i læsbart format

Det er et krav, at sagsprocesoverblikket skal kunne printes i et læsbart format uden yderligere bearbejdning.

199 200

3.230 K Eksport af datasæt til viderebearbejdning i andet modul/system

Det er et krav, at sagsprocesoverblikket som datasæt kan eksporteres til andet modul/anden applikation til videre databearbejdning/afrapportering.

200 201

3.231 K Beskrivelse af funktionalitet til dannelse af sagsprocesoverblik


Info. 44*

759

7.1.11 Hent information til sagsbehandling - delarbejdsgangI forbindelse med behandlingen af sager og dokumenter har brugerne behov for at kunne hente informationer uden for Løsningen. Det kan være ustruktureret information i form af oplysninger fra intranet- og/eller hjemmeside samt andre former for henvisninger, der måtte være relevante for sagen, fx baggrundsrapporter, virksomhedsplaner, evalueringer mv. Det kan også være søgeresultater på eksisterende varemærker eller patentansøgninger, som har juridisk betydning for udstedelsen af rettigheden.

Side 90 af 198

Hent information til sagsbehandling

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.232 K Hent information til sagsbehandling – Opfyldelse af usecase

Løsningen skal kunne understøtte aktøren, således at der kan hentes information til sagsbehandlingen som beskrevet i usecase ”11 Hent information til sagsbehandling”.

Underbilag 3.2 Usecase ”11 Hent information til sagsbehandling”

- 690

3.233 K Beskrivelse af systemstøtte til at hente information til sagsbehandling

Leverandøren skal beskrive, hvorledes behovet, som skitseret i usecase ”11 Hent information til sagsbehandling” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

- 760

3.234 K Tilknytning af information

Det er et krav, at Løsningen kan tilknytte informationer til sagen med et minimum af metadata, således at det er muligt at skelne mellem disse baggrundsinformationer og normalt journaliserede dokumenter. Formatet af informationerne kan være pdf-, odf-, txt-, doc-, hmtl-filer, links mv.

201 202

3.235 K Tilknytning af statiske og dynamiske links og html-sider

Det er et krav, at Løsningen giver mulighed for at tilknytte både dynamiske og statiske html-sider og links fra intra- og internet mv. til en sag.

202 203

Side 91 af 198

Hent information til sagsbehandling

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.236 K Overblik over og opdeling af sagsdokumenter og information hentet til sagen

Det er et krav, at Løsningen giver sagsbehandleren mulighed for at opdele og få et overblik over, hvad der er reelle sagsdokumenter, og hvad der er tilknyttet baggrundsinformation.

203 204

3.237 K Beskrivelse af funktionalitet til indhentning af data til sagen


Info. 45*

761

7.1.12 Ekstern høring – delarbejdsgang Kunden har i forskellige situationer behov for at kunne foretage en ekstern høring, inden der træffes en afgørelse. En høring betegner den situation, hvor Kunden præsenterer et forslag for en eller flere personer eller myndigheder med henblik på, at disse kommenterer det fremlagte materiale. Alt afhængig af retsgrundlaget for den konkrete situation kan det være frivilligt at gennemføre en høring og gøre brug af høringssvaret. I visse tilfælde er det lovbestemt, at offentlige myndigheder skal foretage en høring. Partshøring betegner fx den pligt en myndighed har til at gøre en part bekendt med visse typer af oplysninger, så parten har mulighed for at afgive en udtalelse inden myndigheden træffer en afgørelse.

Side 92 af 198

Ekstern høring - delarbejdsgang

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.238 K Understøttelse af ekstern høring

Det er et krav, at Løsningen understøtter en høring hos én eller flere eksterne parter.

204 205

3.239 K Overblik over proces og indhold

Det er et krav, at det er muligt på en nem måde at se, hvem der har afgivet svar, hvornår de har svaret, og hvad de har svaret.

205 206

3.240 K Understøttelse af ekstern høring

Det er et krav, at høringssvarene registreres og systematiseres med tilhørende metadata mest muligt automatiseret

206 207

3.241 K Dokumentation af høringssvar

Det er et krav, at Løsningen understøtter dokumentationen af en ekstern høring. Hvis selve høringen varetages af et 3. partssystem, skal indkomne kommentarer kunne lagres på den tilhørende sag i Løsningen

207 208

3.242 K Håndtering af indkomne høringssvar

Det er et krav, at Løsningen kan håndtere det/de indkomne høringssvar ved, at sagsbehandleren indarbejder kommentarerne på en nem måde i den oprindelige høringssag, uanset om svarmaterialet modtages digitalt eller i papirform

208 209

3.243 K Beskrivelse af systemstøtte til ekstern høring


Info. 47*

762

Side 93 af 198

Delarbejdsgang Ekstern høring

Omfattede aktører Sagsbehandler

Beskrivelse Delarbejdsgangen har fokus på at understøtte sagsbehandlerens behov i forhold til, at det skal være nemt at sende materialet til de berørte personer, virksomheder, myndigheder, kontorer mv. og at det skal være nemt at se, hvem der har afgivet svar, hvornår de har svaret, og hvad de har svaret (overblik mht. proces og indhold). Behovene for at danne og afsende post til høringsparter er kravspecificeret i afsnit 7.1.6, delarbejdsgangen Danner og afsender post.

Derudover er der fokus på, at høringssvarene journaliseres/registreres og systematiseres med tilhørende metadata mest muligt automatiseret.

Sagsbehandleren skal kunne håndtere høringen både ved, at materialet sendes/modtages digitalt til/fra de personer, der inddrages i processen, samt at materialet og svarene sendes/modtages i papirform og derefter indskannes.

Starttilstand Sagsbehandleren har udarbejdet høringsmaterialet og materialet skal afsendes til en eller flere høringsparter.

Sluttilstand Høringssvarene er registreret og journaliseret på sagen med tilhørende metadata

7.1.13 Behandler aktindsigt – delarbejdsgang Behandling af sager om aktindsigt er i mange tilfælde en meget ressourcetung opgave, idet loven pålægger Kunden, dels at fremfinde samtlige sager og dokumenter, der vedrører ønsket om aktindsigt, men også fordi Kunden skal gennemse og tage stilling til hvert enkelt dokument for at afgøre, om det er omfattet af krav om indsigt. Det er ikke muligt at digitalisere selve skønsudøvelsen, hvorfor der i forhold til denne kravspecifikation ikke stilles krav til den del af sagsbehandlingen, der vedrører skønsudøvelsen. Derimod er det muligt at understøtte den del af sagsbehandlingen, der har at gøre med at finde den eller de sager begæringen om aktindsigt vedrører. Endvidere er det muligt at understøtte den del af sagsbehandlingen, som har at gøre med den visuelle præsentation af selve afgørelsen og danne en kopi af det udvalgte materiale som Kunden beslutter er undergivet aktindsigt.

Behandler aktindsigt – delarbejdsgang

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.244 K Behandler aktindsigt – Opfyldelse af usecase

Løsningen skal kunne understøtte aktøren, således at der kan behandles anmodninger om aktindsigt som beskrevet i følgende usecase ”12 Behandler aktindsigt”.

Underbilag 3.2 Usecase ”12 Behandler aktindsigt”

209** 802

3.245 K Beskrivelse af systemstøtte til behandling af aktindsigt

Leverandøren skal beskrive, hvorledes behovet, som skitseret i usecase ”12 Behandler aktindsigt” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 48**

763

7.2 Centrale behovstemaer og funktionaliteterNedenstående afsnit beskriver kravene til vigtige tværgående temaer og funktionaliteter, der er helt centrale for den samlede løsning (fx Brugervenlighed, Automatisering og Workflow funktionalitet). Systemadministration er placeret her, fordi det rækker ud over de øvrige funktionelle krav beskrevet under delarbejdsgangene.

Side 94 af 198

Fælles for disse behovstemaer og funktionaliteter er, at de er helt afgørende for Kunden, og meget centrale i forhold til at understøtte Kundes ønske om en sammenhængende og brugervenlig Løsning.

7.2.1 Brugervenlighed Kundens brugere stiller høje krav til systemernes funktionalitet og brugervenlighed. Der er efterhånden etableret nogle fælles opfattelser af, hvordan menuer, genvejstaster og funktionalitet til bestemte handlinger er udformet. Det er vigtigt for Løsningens succes, at Løsningen opfylder basale brugervenlighedsforventninger.Kravene til brugervenlighed er forskellige fra bruger til bruger og fra rolle til rolle. Den der arbejder meget med Løsningen, skal kunne arbejde hurtigt via genveje til systemfunktioner mv., hvorimod den der arbejder mindre og mere overordnet med Løsningen skal støttes via intuitiv brugergrænseflade, let genkendelighed, ensartethed mv.Derfor er det af stor betydning, at Løsningen blandt andet fremstår logisk, enkelt, overskueligt og umiddelbart tilgængeligt samt nemt at betjene i de daglige arbejdssituationer. Brugerne skal opleve, at brugergrænsefladen er nem og intuitiv i arbejdet med sager, opgaver, projekter og dokumenter. Tilsvarende skal det være muligt at tilpasse brugergrænsefladen til den enkeltes individuelle præferencer mht. opsætning.

Brugervenlighed

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.246 K Brugervenlighed og let anvendelse

Det er et krav, at Løsningen er brugervenlig og let at anvende. Det betyder, at den enkelte medarbejder efter introduktion til Løsningen skal kunne benytte og arbejde i Løsningen.

210 211

Side 95 af 198

Brugervenlighed

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.247 K Intuitiv brugergrænseflade

Det er et krav, at Løsningen har en intuitiv brugergrænseflade, som er let at anvende.Med intuitiv brugergrænseflade menes der fx:• Få klik• Få skærmbilleder• Få og store/synlige knapper• Mulighed for handikap tilpasning, herunder tilpasning af skærmopløsning*• Anvisning af tastaturgenveje under hensyn til allerede anvendte standarder for tastaturgenveje• Konsistent reaktion på brug af Enter-tasten (bør svare til OK eller Gem-funktionen)• Præsentation af information efter relevans, fx et mindre udsnit af løsningen• ”Hjælp” til handlinger• Genkendelighed i ”look & feel”• Konsistens i anvendelsen af menuer• Overskuelighed• Drag & Drop – fx mellem arkiv og mail• Copy/paste funktion som i kontorautomatiseringsprogrammer• Mulighed for at have flere dokumenter åbne på samme tid• Rollebaseret brugergrænseflade

*Se afsnit 8.8 Brugbarhed og tilgængelighed

211* 815

3.248 K Anskueliggørelse af brugergrænseflade

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.246 – 3.247. Leverandøren kan anvende anskueliggørende beskrivelser, screen-dumps, usecases, flowdiagrammer, brugerudsagn, personabeskrivelser, film eller lignende.

Info. 49*

764

Side 96 af 198

Brugervenlighed

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.249 K Personalisering af brugergrænseflade

Det er et krav, at Løsningen skal have en fleksibel brugergrænseflade, som understøtter forskellige brugertyper. Disse skal fx kunne ændre farve, fonts, placering af knapper, ikoner og lignende

212* 622

3.250 K Personalisering af resultatlister

Det er et krav, at den enkelte bruger kan tilpasse de viste kolonner i resultatlister og derved få præsenteret den for brugeren relevante information under hensyntagen til Løsningens performance

213 214

3.251 MK Personalisering i forhold til brugerprofil

Det er et krav, at Løsningen skal kunne konfigureres til at personalisere brugergrænsefladen, således at indhold og funktionsmuligheder, der præsenteres for den enkelte bruger er tilpasset i forhold til brugerens organisatoriske placering og rettigheder (som bl.a. er givet via brugerprofilen i Kundens brugerrettighedssystem). Det skal muliggøre målrettet sagsrelevant information for den enkelte bruger.

214* 679

3.252 K Personalisering i forhold til den enkelte brugers handlinger

Det er et krav, at Løsningen kan tilpasse brugergrænsefladen baseret på den enkelte brugers handlen og ageren i Løsningen, herunder at Løsningen intelligent kan ”stille forslag” om tilpasninger af løsningen og dennes funktioner.

215 216

Side 97 af 198

Brugervenlighed

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.253 K Anskueliggørelse af muligheder for personalisering


Info. 50*

765

3.254 K Genkendelighed

Det er et krav, at Løsningens brugergrænseflade skal være genkendelig i forhold til brugernes øvrige IT-redskaber (fx browser og kontorautomatiseringsprogrammer), således at løsningen opleves brugervenlig af både den øvede bruger med intensivt brug og af den mindre øvede.

216 217

3.255 K Beskrivelse af genkendelighed

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.254

Info. 51*

766

3.256 K Kontekstafhængig hjælpefunktion

Det er et krav, at Løsningen indeholder en hjælpefunktion, herunder at hjælpefunktionen er kontekstafhængig, således at brugeren får en meningsfuld hjælp i forhold til den aktuelle problemstilling.

217 218

3.257 K Hjælpetekster og ’mouse-over-tekst’

Det er et krav, at Løsningen kan guide brugeren ved brug af forklarende tekst enten i form af fejlmeddelelser, hjælpetekster (der anviser, hvad brugeren skal gøre/indtaste i et felt) eller ved brug af ’mouse-over-tekst’ (der vises, når markøren placeres over metadata felter, drop-down bokse osv).

218 219

3.258 K Handlingsanvisende fejlmeddelelser

Det er et krav, at fejlmeddelelser skal være handlingsanvisende samt umiddelbart forståelige og anvendelige for brugerne

219 220

Side 98 af 198

Brugervenlighed

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.259 K Tilpasning af tastaturgenveje, menupunkter og funktionsknapper

Det er krav, at Kunden har mulighed for at oprette og tilpasse tastaturgenveje på de enkelte funktioner, menupunkter og funktionsknapper.

220* 680

3.260 K Beskrivelse af mulighed for tilpasning af hjælpefunktionalitet


Info. 52*

767

3.261 K Brug af Wizards

Det er et krav, at Løsningen kan tilbyde brug af simple Wizards (guide-funktion fx ved hjælp af navigationssedler), således at mindre erfarne brugere har mulighed for at blive guidet efter trin-for-trin-princippet

221 222

3.262 K Brug af genvejstaster

Det er et krav, at Løsningen i videst muligt omfang kan tilbyde brug af genvejstaster, således at det er muligt at springe direkte til den relevante menu/funktion ved hjælp af tastekombinationer.

222 223

3.263 K Navigation med minimal brug af mus

Det er et krav, at navigationen er opbygget således, at navigering kan finde sted med minimal brug af mus og fx kan aktiveres gennem brug af tabulatortasten eller gennem anvendelse af andre navigationsværktøjer.

223 224

3.264 K Beskrivelse af varierende brugervenlighed


Info. 53*

768

Side 99 af 198

Brugervenlighed

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.265 K Nem journalisering af dokumenter

Løsningen skal give mulighed for nem journalisering af dokumenter til sagerne, f.eks. PDF filer, med brug af maksimum 3 klik. Det skal være muligt at tilknytte dokumenter ved hjælp af ”drag and drop” fra Stifinder, og det skal være muligt at journalisere dokumenter direkte fra Adobe og MS Office.

- 486

3.266 K Journalisering af flere e-mails fra Outlook

Når man anvender Outlook, skal det være muligt herfra at journalisere flere e-mails samtidig samt journalisere alle e-mails i en Outlook-mappe på én gang.

- 571

3.267 O Overblik over billeder i sagen

Det skal være muligt få et grafisk overblik over de til sagen tilknyttede figurer, billeder og tegninger i sagsbehandlingen.

- 578

7.2.2 AutomatiseringKundens nuværende system understøtter i meget høj grad effektive arbejdsprocesser. Det forventer Kunden også af Løsningen.

Side 100 af 198

Automatisering

Krav

Kravtype


PVS ID

3.268 K Løsningens bidrag til automatisering af sagsprocessen

Det er et krav, at Løsningen understøtter funktioner og faciliteter til automatisering af sagsprocessen fra modtagelse af et sagsinitierende dokument til afslutning og aflevering af sag.Fx:• modtagelse og håndtering af standardiseret format (Følgeseddel)• modtagelse og håndtering af ikke standardiseret format (e-post, papir mv.)• genanvendelse af kendte oplysninger ifm. sags- og dokumentoprettelse• dannelse og afsendelse af breve/post/skrivelser• skabeloncenter og massedannelse/-distribuering af dokumenter• procesoverblik og procesunderstøttelse• tiff-konvertering og aflevering til offentligt arkiv

Beskrivelse af alle Kundens processer inkl. diagrammer kan ses h er

224* 835

3.269 K Beskrivelse af Løsningens bidrag til automatisering af sagsprocessen

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.268. Leverandøren kan anvende anskueliggørende beskrivelser, screendumps, usecases, flowdiagrammer, brugerudsagn, personabeskrivelser, film eller lignende.I besvarelsen kan Leverandøren henvise til relaterede kravbesvarelser som led i besvarelsen af dette krav.

Info. 54*

769

7.2.3 Søgning og fremfindingEffektiv og nyttig søgning skal medføre, at alt hvad, der gemmer sig af relevant information i Løsningen kan anvendes i forbindelse med behandlingen af sager og dokumenter. Erfaringen

Side 101 af 198

http://ip-center.dkpto.dk/om-os/udbud/referencer.aspx

er, at det er væsentligt i forbindelse med brugernes anvendelse af Løsningen , at de oplever den nytteværdi, der er forbundet med en hurtig og effektiv søgning og fremfinding af relevante sager og dokumenter, ikke mindst i forhold til understøttelsen af videndeling, internt hos Kunden.Søgning og fremfinding er et centralt tværgående behovstema, der vedrører centrale behov, som gør sig gældende på tværs af delarbejdsgange som fx i forbindelse med oprettelsen af en sag, tilknytning af interessenter og journaliseringen af sager og dokument, etc. Søgning og fremfinding omhandler, hvordan brugeren kan få adgang til data i Løsningen. Søgning er typisk baseret på søgekriterier, der er indtastet eller på anden måde fastlagt. Fremfinding vedrører at få vist data i Løsningen fx via navigation i en stistruktur uden anvendelse af søgekriterier.

Side 102 af 198

Søgning og fremfinding

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.270 K Søgning på metadata om sager

Det er et krav, at det er muligt at søge på alle relevante metadata om sager. Det skal være muligt at søge på et enkelt felt eller på flere felter samtidig. Ved søgning på flere felter skal brugeren kunne angive søgekriterier i relation til det enkelte felt. Hvis brugeren fx vil søge på sagstitel og sagsbehandler, skal der kunne angives et søgekriterium til sagstitel og et andet søgekriterium til sagsbehandler. Det skal desuden være muligt at søge på tværs af felter med angivelse af et fælles søgekriterium. Dvs., at brugeren skal have mulighed for at angive et enkelt søgekriterium, der danner grundlag for søgning i samtlige søgbare sagsfelter samtidig.

225 226

3.271 K Søgning på metadata om dokumenter

Det er et krav, at det er muligt at søge på alle relevante metadata om dokumenter. Det skal være muligt at søge på et enkelt felt eller på flere felter samtidig. Ved søgning på flere felter skal brugeren kunne angive søgekriterier i relation til det enkelte felt, og desuden kunne angive et fælles søgekriterium, der danner grundlag for søgning i samtlige søgbare dokumentfelter samtidig

226 227

Side 103 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.272 K Søgning på metadata om interessenter

Det er et krav, at det er muligt at søge på alle registrerede metadata om en interessent i Løsningen (fx en person eller en virksomhed). Det skal være muligt at søge på et enkelt felt eller på flere felter samtidig. Ved søgning på flere felter skal brugeren kunne angive søgekriterier i relation til det enkelte felt, og desuden kunne angive et fælles søgekriterium, der danner grundlag for søgning i samtlige søgbare interessentfelter samtidig.

227** 712

3.273 K Søgning på metadata og dokumentindhold

Det er et krav, at der skal kunne søges på indholdet af dokumenter i Løsningen. Dette gælder både for egenproducerede dokumenter, indskannede dokumenter og importerede dokumenter – fx dokumenter, der er kommet ind i Løsningen via registrering af e-post. Der skal desuden kunne angives søgekriterier for søgning på dokumenters metadata og dokumenters indhold samtidig.

228 229

3.274 K Søgning relaterede forretningsobjekter

Det er et krav, at Løsningen understøtter søgning via relaterede forretningsobjekter. Fx skal man kunne foretage en sagssøgning ved at angive søgekriterier om tilknyttede dokumenter eller interessenter. Tilsvarende skal man kunne foretage en dokumentsøgning ved at angive søgekriterier om dokumentets interessenter og dokumentets sag.

229** 713

Side 104 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.275 MK Søgning på tværs af forretningsobjekter

Det er et krav, at Løsningen understøtter søgning på tværs af forretningsobjekter. Dvs. at det er muligt at angive et fælles søgekriterium, der danner grundlag for søgning i alle de centrale forretningsobjekter fx sag, dokument og arkiv samtidig.

230 231

3.276 K Søgning gemt som samlemappe på sager og dokumenter i samlemapper

Det er et krav, at en søgning kan gemmes som en samlemappe, der kan tilgås efterfølgende. Samlemappen skal kunne defineres som henholdsvis statisk (søgeresultatet) eller dynamisk (selve søgekriteriet). Ved sager, der er samlet i en samlemappe skal samlemappens sager og dokumenter kunne fremsøges og vises indenfor samlemappens rammer.

Se afsnit 7.2.4 Samlemapper

231** 816

3.277 K Søgning og versioner – søgning på og visning af dokumentversioner

Det er et krav, at der kan søges på et dokument i flere versioner og at alle versioner kan vises i søgeresultatet.

232 233

3.278 K Brugeropsætning - gemte søgninger

Det er et krav, at brugeren kan gemme og navngive et sæt af søgekriterier, så disse kan genanvendes.

233 234

3.279 K Brugeropsætning - publicering af gemte søgninger

Det er et krav, at brugeren kan vælge at publicere en gemt søgning, så søgningen kan anvendes af andre brugere af Løsningen. Herunder både statiske og dynamiske samlemapper


234* 817

Side 105 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.280 K Brugeropsætning - oprettelse abonnementer

Det er et krav, at brugeren kan opsætte abonnementer, der sikrer, at brugeren adviseres, hvis bestemte søgekriterier – fx navngivne søgninger – er opfyldt.

235 236

3.281 K Brugeropsætning - opsætning af søgebilledet

Det er et krav, at brugeren kan opsætte sit søgebillede, så det starter op med faste søgekriterier, der skal kunne ændres inden søgningen igangsættes. Kravet kan evt. imødekommes ved, at brugeren kan ’fryse’ de sidst anvendte søgekriterier

236 237

3.282 K Søg videre - indsnævring af søgeresultat

Det er et krav, at søgningen kan indsnævres. Med udgangspunkt i et søgeresultat skal brugeren kunne søge videre ved at tilføje søgekriterier, der indsnævrer søgningen.

237 238

3.283 K Søg videre - udvidelse af søgeresultat

Det er et krav, at søgningen kan udvides. Med udgangspunkt i et søgeresultat skal det være muligt at udvide med yderligere søgninger ved at angive søgekriterier, der udvider søgningen. Ved udvidet søgning skal Løsningen sikre imod redundans, så hvert hit kun forekommer én gang

238 239

Side 106 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.284 K Søgning ved brug af gængse søgeoperatorer

Det er et krav, at gængse søgeoperatorer kan anvendes, fx:• at indholdet i tekstfelter kan højre- og venstretrunkeres• at der i datofelter kan søges på datointervaller og perioder, der ligger før eller efter en given dato osv.• at der kan vælges fra lister med faste værdier (dropdown-lister), hvor det er relevant• at der kan anvendes boolsk logik (fx AND OR NOT).

239 240

3.285 K Hjælp til søgning

Det er et krav, at en beskrivelse af Løsningens søgefunktionalitet og søgeoperatorer er let tilgængelig i forbindelse med søgningen. Kravet kan evt. imødekommes ved, at hjælpetekst til søgning forekommer i Løsningens online-hjælp eller fremgår via pop-ups til de enkelte søgefelter.

240 241

3.286 K Fremfinding via navigation

Det er et krav, at Løsningen giver mulighed for, at man kan navigere/browse sig frem til data uden at foretage en egentlig søgning. Fx ved, at arkivstrukturen vises som et filsystem.

241 242

3.287 K Fremfinding via virtuelle mappestrukturer

Det er et krav, at Løsningen giver mulighed for, at man kan navigere sig frem til sager og dokumenter via virtuelle mappestrukturer baseret på metadata


242* 818

3.288 K Beskrivelse af funktionalitet til fremfinding


Info. 55*

770

Side 107 af 198

7.2.4 SamlemapperArkivstrukturen hos Kunden afspejler Kundens måde at opdele og tilgå sager og dokumenter på. Eksempelvis afspejler sagsarkivet organisationsstrukturen, sagstyper og emnesystematik. Det er centralt, at sager og dokumenter kan tilgås iht. til denne struktur. Dels af sikkerhedsmæssige årsager og dels pba. arkiverings- og afleveringsmæssige årsager. Hver forvaltningsmæssige enhed har sine egne sager og dokumenter enten tilknyttet en sag eller tilknyttet et specifikt delarkiv. Dokumenter tilgås og fremsøges ofte ud fra eksempelvis deres sag eller deres indplacering i emnesystematikken. For Kunden er der ad hoc - og i nogle tilfælde løbende - et behov for at kunne tydeliggøre sammenhæng mellem sager, dokumenter og aktiviteter på alternative og varierende måder. En sådan sammenhæng er i det følgende kaldt en samlemappe. En samlemappe kan være udtryk for – og være oprettet på baggrund af – en søgning. Eksempelvis skal det være muligt at gemme et søgeresultat som en statisk mappe eller selve søgekriteriet som en dynamisk mappe, hvor søgningen udføres hver gang mappen vælges/tilgås. Yderligere skal det være muligt at tilgå sager og dokumenter via hierarkiske mappestrukturer. Det kan fx være en klassisk stifinderstruktur afspejlende Løsningens arkivstruktur eller det kan være en virtuel mappestruktur baseret på metadata i systemet.

Samlemapper

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.289 K Oprettelse af samlemapper

Det er et krav, at Løsningen giver brugeren mulighed for at oprette samlemapper i form af statiske mapper, som viser det/de systemelementer brugeren manuelt overfører til mappen eller dynamiske mapper, som viser udfaldet af et specifikt søgekriterium.

243 244

3.290 K Indhold i samlemapper som henvisninger

Det er et krav, at Løsningen understøtter, at indholdet i samlemapper oprettes som henvisninger til de systemelementer, der placeres i eller er omfattet af samlemappen. Et dokument eller en sag kan således optræde i mange forskellige samlemapper uden, at sagen/dokumentet kopieres.

244 245

Side 108 af 198

Samlemapper

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.291 K Samlemapper på baggrund af en søgning

Det er et krav, at Løsningen giver den enkelte systembruger mulighed for at benytte en søgning som udgangspunkt for oprettelse af en samlemappe. Mappen skal kunne oprettes som enten objektspecifik (sag eller dokument mv.) eller tværgående/global og skal kunne afspejle det konkrete resultat (statisk samlemappe) eller det konkrete søgekriterium (dynamisk samlemappe).

245 246

3.292 K Overførsel af sager, dokumenter, aktiviteter mv. til statiske samlemapper

Det er et krav, at Løsningen giver brugeren mulighed for at overføre sager, dokumenter, aktiviteter mv. til statiske samlemapper på en for brugeren let måde. Det kan fx være via drag-and-drop eller ved markering og valg af funktion til overførsel til samlemappe.

246 247

3.293 K Tilgængelighed af samlemapper relevante steder i løsningen

Det er et krav, at Løsningen giver mulighed for, at samlemapper kan tilgås relevante steder i Løsningen. Det kan være i søgebilleder, favoritvisninger, åbningsbilleder for såvel systemet som specifikke projekter og sager mv.

247 248

3.294 K Dynamiske samlemapper med dynamiske søgekriterier

Det er et krav, at Løsningen giver mulighed for at oprette samlemapper, der gør brug af dynamiske kriterier. Fx skal det være muligt at definere en samlemappe for Mine sager eller Min afdelings sager, hvor indholdet af mappen varierer afhængigt af, hvem der aktiverer mappen.

248 249

Side 109 af 198

Samlemapper

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.295 K Dynamiske mappestrukturer med sager eller dokumenter

Det er et krav, at Løsningen kan vise sager og dokumenter i dynamiske mappestrukturer. Mappestrukturer skal kunne foldes ud, så man kan navigere sig frem til den rigtige gruppe af sager eller dokumenter. Strukturen kan være udtryk for den fysiske arkivstruktur (fx Arkiv/Delarkiv/Emnesystematik) eller en metadatabaseret struktur (fx Sagstype/Emnesystematik), hvor sager og eller dokumenters metadataopmærkning benyttes til at indplacere dem i en virtuel mappestruktur.

249 250

3.296 K Dynamisk mappestrukturer på sager

Det er et krav, at Løsningen giver mulighed for, at gøre brug af metadatabaserede mappestruktur på sager. Det kan fx være på sager med meget store dokumentmængder, at dokumenterne vises i en virtuel mappestruktur baseret på fx Dokumentgruppe/Dokumenttype/Dokumentstatus – således at brugeren let kan navigere sig frem til fx alle egenproducerede dokumenter af dokumenttypen Indstillinger med status Godkendt.

250 251

3.297 K Beskrivelse af samlemappefunktionalitet


Info. 56*

771

Side 110 af 198

7.2.5 SystemadministrationLøsningen vil blive et system i konstant forandring, og der vil jævnligt blive udført mindre eller større justeringer eller ændringer i Løsningen. For at administrationsopgaven ikke bliver en tung byrde for Kunden, er det nødvendigt, at den daglige og løbende vedligeholdelse kan udføres af udvalgte interne medarbejdere. Tilsvarende skal den funktionalitet, der stilles til rådighed for systemadministratoren være af en sådan beskaffenhed og tilgængelighed, at det ikke skaber flaskehalsproblemer hos Kunden at administrere Løsningen. Hvis ikke det er tilfældet, bliver leverandørafhængigheden for stor. Funktionelle krav til systemadministration dækker over de koncepter og værktøjer, som Løsningen skal stille til rådighed for systemadministrator. Opgaven med at administrere Løsningen indebærer blandt andet: ejerrettigheder over alle sager og dokumenter opsætning af standard indstillinger for brugere/roller/enheder mv. oprettelse af nye sagstyper, dokumenttyper, felter, roller mv. tilpasning af værdier i tabeller, lister mv. oprettelse/administration af brugere, brugergrupper, adgangs- og indbliksgrupper mv. via

Kundens Active Directory redigering af diverse systembeskeder, fejlmeddelelser mv. opsætning af overførsel af metadata mellem Løsningen og kontoradministrationssystem

Tekniske krav til systemadministration, se afsnit 8. Ikke-funktionelle krav.

Systemadministration

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.298 K Oprettelse og vedligeholdelse af nye skabeloner

Det er et krav, at brugeren let skal kunne oprette og vedligeholde dokumentskabeloner med eller uden flettefelter, baseret på rollerettigheder.

271 272

3.299 K Administration fra fuldskærm brugergrænseflade

Det er et krav, at alle ofte udførte administrationsopgaver kan udføres fra en fuldskærms og ikke-kodebaseret brugergrænseflade.

272* 666

Side 111 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.300 MK Konfigurerbarhed af Løsningen

Det er et krav, at brugergrænsefladen er så fleksibel som mulig, herunder at alle links, felter, datoer og grænseværdier ikke skal hard-kodes, men kan tilføjes, ændres og fjernes via konfiguration i administrationsmodulet.

273** 274

3.301 K Konfigurering af lukke- og helligdage

Til brug for friststyringen skal det være muligt at konfigurere, hvilke dage der er arbejdsdage og hvilke dage, der er lukkedage eller helligdage.

- 686

3.302 K Konfigurering af genvejstaster

Det er et krav, at genvejstaster ikke skal hard-kodes, men kan konfigureres.

274** 275

3.303 Slettet

3.304 K Beskrivelse vedrørende konfigurerbarhed Leverandøren bedes beskrive, om det er muligt at tilknytte nye selvudviklede felttyper, og om der kan oprettes nye skærmbilleder i Løsningen.

- 803

3.305 K Bevaring af konfigurering ved opdatering

Det er et krav, at opsatte konfigureringer ikke ændres eller slettes i forbindelse med opdateringer.

- 837

Side 112 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.306 MK Opsætning af metadata på sager og dokumenter

Det er et krav, at det er opsætbart, hvilke metadata Løsningen skal foreslå ved oprettelse af sag eller dokument. Opsætningen skal kunne foretages centralt og gælde for alle brugere og/eller lokalt og gælde for den enkelte bruger eller brugerprofil, og det skal være muligt at definere, hvilke metadata, der er obligatoriske. Opsætningen skal basere sig på udfyldning af andre felter i forbindelse med registreringen – fx sagstype, dokumenttype eller andet

275 276

3.307 MK Oprettelse af sagstyper, dokumenttyper, felter, roller mv.

Det er et krav, at systemadministrator kan oprette nye entiteter og gøre dem tilgængelige for relevante aktører fra en fuldskærms og ikke-kodebaseret brugergrænseflade. Nye entiteter kan være:

• sagstyper• dokumenttyper• dokument/filskabeloner• felter• værdilister• sags- og dokumentroller• mv.

276 277

Side 113 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.308 K Afhængigheder mellem systementiteter og værdier

Det er et krav, at systemadministratoren kan opsætte styrende afhængigheder mellem systementiteter. Afhængighederne kan gå på at:• begrænse brugen af felter til udvalgte sags- og/eller dokumenttyper• begrænse udsnittet af en værdiliste til udvalgte sags- og dokumenttyper• begrænse tilgangen til dokumentskabeloner til udvalgte dokumenttyper• mv.

277 278

3.309 MK Tilgang og administration af tabeller, parametre mv.

Det er et krav, at samtlige referencetabeller, systemtabeller og parametre i Løsningen kan tilgås og administreres fra en fuldskærms og ikke-kodebaseret brugergrænseflade.

278 279

3.310 MK Let tilgængelig dokumentation af ændringer foretaget i Løsningen

Det er et krav, at Løsningen inkluderer hjælpeværktøjer til dokumentation af de udførte ændringer af referencetabeller og værdisæt i Løsningen. Disse værktøjer skal være opbygget efter samme principper som den øvrige løsning fx i form af en browser baseret tilgang.

279 280

3.311 K Digital overførsel af administrative data

Det er et krav, at udvalgte administrative data, fx brugeradministrative data, registre, følgetekster i værdilister etc., kan overføres digitalt, fx via en webservice.

280 281

Side 114 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.312 MK Tildeling af roller og rollespecifikke rettigheder

Det er et krav, at brugeradministrationen kan omfatte tildeling af forskellige roller, og at brugerne dermed i hver rolle har forskellig adgang til sager og dokumenter. Rollerne kan være personlige, organisatoriske eller klassificeret i grupper – fx i relation til aktuel projektdeltagelse.

281 282

3.313 K Samlet brugeradministration for alle dele af Løsningen

Det er et krav, at brugeradministratoren skal have ejerrettigheder til alle sager og dokumenter i den samlede Løsning - kernefunktionalitet samt eventuelle tillægsmoduler - under anvendelse af de samme koncepter og værktøjer.

282 283

3.314 K Funktionalitet til afprøvning/visning af ændringer

Det er et krav, at systemadministrator kan afprøve/få vist, hvordan ændringer foretaget via administratormodulet ser ud, inden de gøres tilgængelige for brugerne. Det kan fx være via et WYSIWYG lignende værktøj, der gør at ændringer kan previewes i en browser inden de effektueres.

283 284

3.315 K Beskrivelse af koncepter og værktøjer til brugervenlig systemadministration

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.298 – 3.303 og 3.305 – 3.314.

Info. 60*

772

Side 115 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.316 K Overvågning og optælling af fejl tilgængeligt for systemadministrator

Det er et krav, at fejlsituationer logges i en central fejllog, som giver systemadministrator adgang til at overvåge og optælle fejl uanset, om brugeren vælger selv at fejlrapportere.

284 285

3.317 K Søg- og sorterbar systemlog/fejllog

Det er et krav, at Løsningens logs – inkl. fejlloggen – opbygges med relevante felter, og at felterne gøres søgbare, fx via administrationsværktøjet, eller det skal være muligt at fremfinde fejl via en søgeprofil.

285** 286

3.318 K Administration af brugerrettede system- og fejlmeddelelser

Det er et krav, at systemadministrator kan redigere system- og fejlmeddelelser fra Løsningen til brugeren pba. observerede og registrerede fejl- og system-meddelelser.

286 287

3.319 K Beskrivelse af funktionalitet til arbejde med fejl og meddelelser


Info. 61*

773

7.2.6 Workflow funktionalitetI de fleste af Kundens opgaver er der høje krav til dokumentation og styring af sagsbehandlingen. Det gælder især i rettighedssager, at der er krav om ensartet og dokumenteret sagsgang. Kunden har i snart 15 år haft fuld IT-understøttelse af sin sagsbehandling, og det er derfor helt centralt, at arbejdsgangene også i den nye Løsning er automatiseret i så høj grad som muligt.Løsningen skal derfor omfatte fuld integreret workflow-funktionalitet til processering og kvalitetssikring af sager og dokumenter, herunder fristovervågning, regler for hændelser, statusskift, godkendelse af dokumenter mv.

Side 116 af 198

Krav til den mere simple form for workflow er også beskrevet i afsnit 7.1.2, Behandler sag, da det forventes at være en del af Løsningens standard funktionalitet. Krav til Løsningen, der gør den i stand til at fungere som medspiller i tværgående proces- og systemsammenhænge, er af teknisk karakter og er beskrevet i afsnit 8.6 Integration.

Workflow funktionalitet

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.320 K Workflowbaseret styring

Det er et krav, at der for workflowbaseret styring i Løsningen gælder følgende:- at hændelser i workflows kan initiere oprettelse eller nedlæggelse af frister- at oprettelse eller udløb af frister kan initiere hændelser- at hændelser kan være afhængig af betingelser- at hændelser kan initiere andre hændelser i samme workflow / overworkflow / underworkflow- at hændelser kan initiere flytning af objektet til en anden sagspulje- at muligheden for oprettelse af frister er afhængig af brugerens rolle- at det er muligt at opsætte frister, så sagsbehandleren modtager en advis ved udløb af fristen- at det er muligt at opsætte generering af dokumenter, så de automatisk udskrives og/eller journaliseres, fx når en anden hændelse oprettes, eller en frist udløber.Funktionaliteten skal være knyttet til bestemte brugerrettigheder.- at de enkelte workflow løbende kan omkonfigureres, og nye kan oprettes- at der er en grafisk brugergrænseflade til konfigurering af workflowene

- 460

Side 117 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.321 MK Opsætning af workflowbaseret styring af arbejdsgangen

Det er et krav, at arbejdsgange kan understøttes med sagsstyring i form af mulig opsætning af workflowfunktionalitet af større eller mindre kompleksitet

345** 346

3.322 MK Løsningen som aktør i et workflow

Det er et krav, at Løsningen kan bidrage som aktør ifm. afviklingen af et workflow. Fx at Løsningen kan stille logik og grænseflade til rådighed på baggrund af en hændelse, der aktualiserer en aktivitet, som Løsningen ifm. orkestreringen er givet ansvaret for.

Hændelser, statusskift og workflows i Løsningen skal kunne initieres via et servicekald fra et eksternt system

346** 347

3.323 MK System initieret igangsætning af arbejdsgang

Det er et krav, at Løsningen kan igangsætte en på forhånd defineret arbejdsgang. Arbejdsgangen skal kunne igangsættes på baggrund af en prædefineret starthændelse - fx oprettelse af en specifik type af sag (fx patentsag/designsag), ved modtagelse og journalisering af en specifik type af dokument etc.

347** 630

Side 118 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.324 MK Skabeloner på hændelser

Det er et krav, at Løsningen kan arbejde med et sæt skabeloner på hændelsesniveau. På hændelsesniveau er skabelonen et afgrænset udfaldsrum af de samlede mulige hændelsesforløb og muligheder for feedback (fx ”godkendt”, ”godkendt med bemærkninger”, ”retur til sagsbehandler til fornyet behandling” mv.).

348** 349

3.325 MK Rollebetinget sagsstyring

Det er et krav, at Løsningen kan arbejde med roller eller rettigheder, således at det fx kan specificeres, hvem der har mulighed for og/eller har pligt til godkende/beslutte sagens videregivelse til næste trin.

349 350

3.326 K Styring af hændelser

Det er et krav, at når en bestemt arbejdsgang initieres på en sag, indgår denne sag i en dokumentations- og styringsproces, der indeholder flere formelle godkendelsestrin end processen for en ”almindelig” sag. (Det skal fx fremgå, hvilke interne personer, der har set sagen, hvornår og hvilke kommentarer/godkendelser/ afvisninger, som dette har medført).

350 351

3.327 K Dokumentation af hændelser og produkter

Det er et krav, at Løsningen skal kunne levere dokumentation for alle forudgående produkter og hændelser i behandlingen af en sag.

351** 805

Side 119 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.328 MK Fleksibilitet

Det er et krav, at Løsningen skal være enkel at konfigurere, ændre, anvende og afvige fra. Fra centralt hold (fx fra politisk og juridisk afdeling) og fra lokalt hold (sagsbehandlerperspektiv), skal det være muligt at afvige i forhold til et prædefineret forløb.

352** 631

3.329 K Beskrivelse af workflow funktionalitet


- 838

Side 120 af 198

7.3 Øvrige behovstemaer og funktionelle krav

7.3.1 Skanning og OCR Skønt stadig mere post tilgår Kunden elektronisk, vil der i de kommende år fortsat være en del post, der modtages per papir. Følgelig er det et væsentligt krav, at Løsningen har, eller integrerer til en skanningsløsning/et skanningsmodul, således at posthåndteringen og -digitaliseringen kan ske gnidningsfrit med øget mulighed for at lette Kundens opgave med opmærkning, registrering/journalisering af digital, men ustruktureret information.Forudsætningen for at digitalisere modtaget post indebærer ligeledes, at posten skannes og ofte OCR-behandles. Ved OCR-behandling bliver det muligt efterfølgende at udnytte teksten i forbindelse med registrering af dokumentet i Løsningen, samt at foretage en viderebearbejdning i et kontorautomatiseringssystem og til brug for fritekstsøgning.

Scanning og OCR

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.330 K Modtagelse af indskannede dokumenter

Det er et krav, at Løsningen kan modtage indskannede dokumenter.

287 288

3.331 K Lagring af indskannede dokumenter med automatisk påførsel af metadata

Det er et krav, at brugeren kan lagre indskannede dokumenter i Løsningen med automatisk påførsel af metadata til journalisering, sortering og fordeling - herunder tilknytning af relevant sag, sagsbehandler og organisatorisk enhed ved hjælp af stregkodeark, der skannes sammen med dokumentet.

288 289

3.332 K Indskanning af dokumenter med forskellige metadata

Det er et krav, at skanningsløsningen understøtter, at en samlet mængde post med forskellige metadata kan skannes i én arbejdsgang, fx via skilleark mellem de forskellige dokumenter

289 290

Side 121 af 198

Scanning og OCR

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.333 K Skanning af forskellige typer af dokumenter

Det er et krav, at skanningsløsningen understøtter skanning af forskellige typer dokumenter – herunder dokumenter med grafik og billeder.

290 291

3.334 K Viderebehandling af indskannede tekstdokumenter

Det er et krav, at skanningsløsningen understøtter en viderebehandling af indskannede tekstdokumenter, så der kan søges på dokumentindhold, når dokumenterne er lagret i Løsningen.

291 292

3.335 MK Skanning i sort/hvid, gråtoner og farver

Det er et krav, at skanningsløsningen kan håndtere dokumenter i sort/hvid og gråtoner, samt farver.

292 293

3.336 MK Skanning af dokumenter i forskellige størrelser/formater

Det er et krav, at skanningsløsningen kan håndtere indskannede dokumenter i formaterne A0-A5.

293 294

3.337 MK Konvertering af billede til søgbar fil via OCR-facilitet

Det er et krav, at skanningsløsningen kan tilbyde en OCR-facilitet i de tilfælde, hvor der er tale om skanning af tekstdokumenter, der kan konvertere det digitale billede til en fritekstsøgbar fil. Det skal være muligt at anvise ønsket format for konverteringen (fx txt, rtf, søgbar pdf)

294 295

Side 122 af 198

Scanning og OCR

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.338 MK Understøttelse af det latinske alfabet inkl. danske karakterer

Det er et krav, at Løsningen kan genkende det latinske alfabet inkl. de danske specialkarakterer æ, ø og å.

295 296

3.339 K Stavekontrol som del af OCR-proces

Det er et krav, at skanningsløsningen kan understøtte, at dansk og engelsk stavekontrol er indbygget og kan aktiveres som del af OCR-processen.

296 297

3.340 K Afvikling af OCR-processen i baggrunden

Det er et krav, at skanningsløsningen kan give mulighed for, at OCR-processen kan 'køre' i baggrunden, mens det indskannede dokument fordeles og eventuelt registreres. Eksempelvis kan OCR-processen, mens der foregår en registrering af dokumentet, og når OCR-processen er afsluttet, gemme det 'oversatte' dokument automatisk sammen med det oprindelige dokument

297 298

3.341Øn

K Bibeholdelse af formateringer i dokumentet

Det er et krav, at skanningsløsningen ifm. skanning og OCR kan bibeholde basale formaterings- og layoutmæssige elementer. Fx skal det kunne adskille kolonner korrekt samt have automatisk genkendelse og adskillelse af billeder og tekst.

298 299

3.342 K Genkendelse af standard skrifttyper ifm. OCR

Det er et krav, at skanningsløsningen kan genkende alle standard skrifttyper med meget høj grad af genkendelighed/lav fejlprocent ifm. OCR-behandlingen.

299 300

Side 123 af 198

Scanning og OCR

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.343 K Kvalitetskontrol ifm. skanning

Det er et krav, at skanningsløsningen kan understøtte systematisk kvalitetskontrol af skanningsprocessen, således at det sikres, at:• de skannede billeder kan læses• alle sider er blevet skannet korrekt• registreringen er tilstrækkelig• fejlskannede dokumenter opmærkes og re-skannes• fejlskannede dokumenter ikke forveksles med korrekt skannede• genkendelse af tomme dokumenter

300 301

3.344 K Forbedring af kvalitet på indskannede dokumenter

Det er et krav, at skanningsløsningen har faciliteter, der gør det muligt at forbedre kvaliteten af det indskannede dokument i form af:• opretning af “skæve sider”• vending af sider• ændring af toningen i det indskannede dokument

301 302

3.345 K Logning af data i forbindelse med skanning

Det er et krav, at skanningsløsningen med henblik på dokumentidentifikation kan understøtte logning i form af tidsstempling, identifikation af skanningsoperatør og dokumentnummer som dokumentation for den udførte skanning af det enkelte dokument

302 303

Side 124 af 198

Scanning og OCR

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.346 K Skanning og journalisering i samme arbejdsgang

Det er et krav, at skanningsløsningen kan understøtte, at skanningsprocessen kan tilrettelægges, så journalisering også kan foretages i samme arbejdsgang som indskanningen

303 304

3.347 K Opdeling af relaterede dokumenter med fastholdelse af relation

Det er et krav, at det ved indskanning er muligt at håndtere en opdeling i hoveddokument (breve) og underdokumenter (bilag) med markering af eventuelt ikke indskannede bilag, der distribueres i papirform. Tilsvarende skal det være muligt at bibeholde sammenhængen mellem dokumenterne, så den fremstår tydeligt i Løsningen efter indskanning.

304 305

3.348 K Zoomfunktion i skanningsmodul

Det er et krav, at skanningsløsningen kan tilbyde en lupfunktion, der gør det muligt at zoome ind og ud i det skannede dokument.

305 306

Side 125 af 198

Scanning og OCR

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.349 K Optisk læsning, automatik og logik

Det er et krav, at skanningsløsningen kan understøtte optisk læsning af eksempelvis et tal eller kode, som er påført visse dokumenter i forbindelse med indskanning. Den optiske læsning skal give mulighed for, at skanningsløsningen ved hjælp af det anførte tal/kode kan foretage automatisk journalisering, sortering og fordeling af dokumenter til sagsansvarlige organisatoriske enheder/medarbejdere. Eksempelvis modtagelse af standardblanketter, eller prædefinerede felter som skanningsmedarbejder påfører manuelt før skanning.

306 307

3.350 K Understøttelse af forskellige afleveringsformater/releasescripts

Det er et krav, at skanningsløsningen kan understøtte aflevering/frigivelse/release af data til Løsningen via forskellige filformater. Fx skal skanningsløsningen kunne aflevere data i OIO XML format og i det gældende Følgeseddelformat.

307 308

3.351 K Beskrivelse af skanningsløsningens håndtering af skanningsopgaven


Info. 62*

774

3.352 K Indskanning af post fra 3. part

Det er et krav, at Løsningen kan understøtte at en 3. part står for indskanning af post, herunder at krav til formater på den skannede post og metadata er angivet.

308 309

Side 126 af 198

Scanning og OCR

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.353 K Beskrivelse af mulighed for at lade 3.part stå for indskanning


Info. 63*

775

Side 127 af 198

7.3.2 Dagsorden- og udvalgsbehandling Kunden har behov at få understøttet udarbejdelsen af en sagsfremstilling og en dagsorden i forbindelse med afholdelse af udvalgsmøder, administrative møder, ledelsdesmøder mv. Brugeren skal kunne generere en dagsorden på en nem måde og kunne tilknytte sagsfremstillinger og evt. bilag til den enkelte mødedagsorden. Der er behov for at kunne styre udarbejdelsen af dagsordenspunkter og den tilhørende sagsfremstilling undervejs i processen. Denne styring kan håndteres fx med sags- og dokumentreferencer, adviser og oplysninger om redigeringsrettigheder i forhold til den enkelte sag.Når mødet er blevet afholdt har brugeren behov for automatisk at få arkiveret udvalgsbeslutningen i tilknytning til den sagsfremstilling med tilhørende indstilling, der er blevet anvendt som beslutningsgrundlag for udvalget.

Dagsorden- og udvalgsbehandling

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.354 O Udarbejder sagsfremstilling til dagsorden – Opfyldelse af usecase

Det er et krav, at Løsningen kan understøtte aktøren, således at der kan udarbejdes en sagsfremstilling til en dagsorden som beskrevet i følgende usecase ”13 Udarbejder sagsfremstilling til dagsorden”.

Underbilag 3.2 Usecase”13 Udarbejder sagsfremstilling til dagsorden

309 310

3.355 O Beskrivelse af systemstøtte til udarbejdelse af sagsfremstilling til dagsorden

Leverandøren skal beskrive, hvorledes behovet som er skitseret i usecase ”13 Udarbejder sagsfremstilling til dagsorden” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 64**

776

Side 128 af 198

Dagsorden- og udvalgsbehandling

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.356 O Udarbejder dagsorden og referat – Opfyldelse af usecase

Det er et krav, at Løsningen kan understøtte aktøren, således at der kan udarbejdes en dagsorden som beskrevet i usecase ”14 Udarbejder dagsorden og referat”.

Underbilag 3.2 Usecase ”14 Udarbejder dagsorden og referat

310 795

3.357 O Beskrivelse af systemstøtte til udarbejdelse af dagsorden og referat

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”14 Udarbejder dagsorden og referat”, opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 65**

777

3.358 O Understøttelse af dagsorden- og udvalgsbehandling

Det er et krav, at Løsningen opfylder FESD I standarden for udvalgsbehandling eller tilsvarende.

Se kapitel 8 Ikke-funktionelle krav

311* 819

7.3.3 ForelæggelseFor at opnå en smidig og fuld digital sagsbehandling hos Kunden, er det centralt, at alle led i forelæggelsen (fra fuldmægtig til direktøren) anvender Løsningen. I den forbindelse er det centralt, at sager, der gennemgår et godkendelsesforløb opad i organisationen, understøttes bedst muligt. Et typeeksempel er at en sagsbehandler forelægger et udkast til svar på et spørgsmål fra Folketinget først for sektionschefen, dernæst for enhedschefen, herefter for vicedirektøren eller direktøren, før svaret går videre til departementet. I arbejdsgangen kan en chef enten godkende eller returnere med/uden rettelser/ændringer til udkastet.Dette arbejde medfører potentielt anvendelse af en række versioner af det / de samme notater, som er blevet forelagt.

Side 129 af 198

Afsnittet er en uddybning af funktionaliteten i afsnit 7.2.6 Workflow funktionalitet.

Side 130 af 198

Forelæggelse

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.359 O Gennemfører Forelæggelse – Opfyldelse af usecase

Løsningen skal kunne understøtte aktøren, således at der kan gennemføres Forelæggelser, som beskrevet i følgende usecase ”15 Gennemfører Forelæggelse”.

Underbilag 3.2 Usecase ”15 Gennemfører Forelæggelse

312 313

3.360 O Beskrivelse af systemstøtte til gennemfører Forelæggelse

Leverandøren skal beskrive, hvorledes behovet, som er skitseret i usecase ”15 Gennemfører Forelæggelse” opfyldes. Der ønskes en konkret skitsering af den arbejdsgang, som aktøren involveres i på samme detailniveau, som fremgår af eksemplet i usecasen.

Info. 67**

779

3.361 O Faste Forelæggelsesforløb

Det er et krav, at hver forelæggelsesejer kan have et default valg af personer, der indgår i processen Forelæggelse, som der kan afviges fra. (Fx aktuel sagsbehandler – sektionschef – kontorchef – direktør).

313** 628

3.362 O Stedfortræder

Det er et krav, at ejeren af Forelæggelsen kan indsætte stedfortræder for de valgte personer, der indgår i Forelæggelsen

314 315

3.363 O Stedfortræder II

Det er et krav, at stedfortræderfunktionen kan anvendes igen, når der opstartes en ny Forelæggelse.

315 316

Side 131 af 198

Forelæggelse

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.364 O Stedfortræder III

Det er et krav, at medarbejderne kan definere faste stedfortrædere, således at en Forelæggelse ligeledes er åbent for redigering af disse personer.

316 317

3.365 O Frister

Det skal være muligt at frister overskrides uden, at det standser den videre gennemførelse af Forelæggelsen. (Ejeren af Forelæggelses-workflowet skal orienteres om, at fristen er overskredet.)

317* 629

3.366 O Grad af væsentlighed

Det er et krav, at en opstartet Forelæggelse kan markeres på 3 niveauer. Fx hastende, standard, ikke hastende.

318 319

3.367 O Typebestemmelse

Det er et krav, at Forelæggelser kan typebestemmes (evt. som fast liste). Fx §20 eller besvarelse af borgerbrev.

319 320

3.368 O Visning af historik

Det er et krav, at det altid er muligt at se, hvor langt Forelæggelsen er kommet i forelæggelsen.

320* 820

3.369 O Visning af historik II

Det er et krav, at historikken viser, hvilke dokumenter (hvilken sag), der er kommenteret, samt om der er oprettet en ny version af dokumentet.

321* 821

Side 132 af 198

Forelæggelse

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.370 O Historik

Det er et krav, at når der vælges en enhed eller et team, som et led i forelæggelsen, så skal det registreres, hvilken person fra det pågældende team, som har gennemført opgaven i Forelæggelsen.

322* 822

3.371 O Fortrolighed

Det er et krav, at det skal være muligt for ejeren af Forelæggelsen, at påsætte indblik (evt. nedarvet fra dokumentet) på Forelæggelsen.

323* 823

3.372 O Orientering

Det er et krav, at der kan sættes aktører, teams eller enheder på de forskellige niveauer i Forelæggelsen til orientering, som ikke har mulighed for aktivt at gribe ind i Forelæggelsen.

324* 824

3.373 O Orientering II

Det er et krav, at alle aktører kan modtage orientering, når et workflow er godkendt af sidste led i workflowet.

325 326

3.374 O Anvendelse af dokumenttilstande

Det er et krav, at både dokumenter i udkast og låste dokumenter kan sættes i Forelæggelse. Anvendelsen af låste dokumenter sikrer, at næste led i forelæggelsen tvinges til at gemme kommentarer i en ny version af dokumentet.

326* 825

3.375 O Anvendelse af noter

Det er et krav, at der kan skrives noter, der relaterer sig til den konkrete proces Forelæggelse.

327* 826

3.376 O Nye aktører

Det er et krav, at alle led i Forelæggelsen kan tilføje eller fjerne led i Forelæggelsen.

328 329

Side 133 af 198

Forelæggelse

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.377 O Ændringer

Det er et krav, at alle ændringer fortaget i et workflow (hvem har gjort hvad) registreres i workflow historikken.

329 330

3.378 O Historik lagt på sagen

Det er et krav, at et workflow (dokumentationen heraf) lægges som en selvstændigt akt på sagen.

330 331

3.379 O Søgning af godkendelser

Det er et krav, at det er muligt, at fremsøge om Forelæggelser er godkendt på forskellige niveauer. Eks. sektionschef-, enhedschef- eller vicedirektørniveau.

331** 804

3.380 O Enhedens Forelæggelser

Det er et krav, at enhedens ikke afsluttede og afsluttede Forelæggelser kan fremsøges på en liste evt. opdelt på perioder og sagstyper

332 333

3.381 O Overskredne frister

Det er et krav, at overskredne frister vises på en overskuelig måde for alle led i Forelæggelsen.

333* 827

3.382 O Adgang til Forelæggelser

Det er et krav, at alle aktører kan fremsøge og se alle ikke afsluttede Forelæggelser på en overskuelig måde med mulighed for opdeling evt. på sagstyper og frister.

334* 828

3.383 O Fremsøge specifikke Forelæggelser

Det er et krav, at det altid er muligt at fremsøge specifikke Forelæggelser og se, hvor langt de er kommet i processen.

335* 829

3.384 O Versioner af Forelæggelsen

Det er et krav, at når der ændres i Forelæggelsen, så kan denne gemmes som en ny version.

336 337

Side 134 af 198

Forelæggelse

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.385 O Registrering af dokumentversioner

Det er et krav, at der automatisk tilknyttes versioner til de enkelte trin i Forelæggelsen, såfremt der er oprettet en ny version af dokumentet.

337 338

3.386 O Overblik over dokumentversioner

Det er et krav, at de enkelte dokumentversioner er synlige i relation til de enkelte procestrin.

338* 830

3.387 O Udvalgte dokumenter

Det er et krav, at et eller flere dokumenter (og bilag) kan sættes i Forelæggelse.

339 340

3.388 O Rækkefølge på dokumenter

Det er et krav, at det er muligt for ejeren af Forelæggelsen at bestemme rækkefølge på de dokumenter, der sættes i workflow

340 341

3.389 O Ændringsmarkeringer

Det er et krav, at anvendte ændringsmarkeringer i dokumenter er synlige i Løsningen og ikke kun ved åbning af Word (dokumentprogrammet).

341 342

3.390 O Vælge dokumenter til print

Det er et krav, at specifikke dokumenter let kan vælges til print fra en Forelæggelse.

342* 831

3.391 O Printmuligheder

Det er et krav, at aktøren kan foretage individuelle valg i forbindelse med udskrivning på den valgte printer. (Fx brevpapir, valg af A3/A4 etc).

343* 832

3.392 O Rækkefølge på print.

Det er et krav, at aktøren kan vælge rækkefølgen på printopgaverne.

344* 833

Side 135 af 198

7.3.4 JournalarksmodulJournalarksmodulet skal støtte sagsbehandlerens kontekstbestemte behov for overblik. Sagsbehandlere har overordnet set to behov, som journalarksmodulet skal dække:

1. Et sted at registrere relevante oplysninger og ”løse noter” fx i forbindelse med en telefonsamtale.

2. Et værktøj til at skabe overblik over, hvad der er sket i en sag i kronologisk rækkefølge og på tværs af enkeltsager (log).

Journalarksmodulet omtales her som et ”modul”, fordi det skal være en selvstændig del af Løsningen. Selve journalarket skal være en visning, dvs. at journalarket dannes dynamisk på baggrund af en konkret forespørgsel (søgning), således at det kan indeholde journalnoter og dokumenter, der afspejler det aktuelle behov for overblik, som sagsbehandleren har behov for i den konkrete situation.Når sagsbehandleren benytter journalarkmodulet som et sted at registrere relevante oplysninger og ”løse noter” (jf. punkt 1 ovenfor), skal vedkommende kunne vælge blandt flere forskellige typer af journalnoter og tilføje en overskrift og tekst til den valgte type af note.Når sagsbehandleren benytter journalarket som en log (jf. punkt 2 ovenfor), fungerer journal-arket som en visning, der giver overblik i forhold til de journalnoter og dokumenter, der er registreret på sagen og hvor i det samlede sagsbehandlingsforløb den valgte sag befinder sig.Dannelse og efterfølgende visning af et journalark skal gemmes som et dokument og om nødvendigt kunne printes, således at journalark, der er dannet i løbet af sagens behandling, også indgår i sagens dokumentation.Journalnoter kan genereres af systemet eller brugeren.

Journalarksmodul

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.393 K Journalnoter skal knyttes til enkeltsager

Det er et krav, at det er muligt at oprette en journalnote i forhold til den eller de sager, hvortil noten indeholder relevante oplysninger

354 355

Side 136 af 198

Journalarksmodul

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.394 K Valg af sag til journalnoten

Det er et krav, at journalnoten som udgangspunkt skal tilføjes den enkeltsag, der er under behandling, men brugeren skal også kunne vælge at føje journalnoten til en anden enkeltsag.

355 356

3.395 K Struktur for journalnoter

Det er et krav, at journalnoter – uafhængigt af typen – har samme struktur og som minimum indeholder følgende oplysninger: • overskrift (fritekst) – nedarves automatisk fra sagen, med mulighed for at bruger redigerer teksten • id for journalnote – oprettes automatisk • id for enkeltsag – nedarves automatisk fra sag • dato for journalnote – oprettes automatisk • opgaveklassifikation – nedarves automatisk fra sagen. Er den samme journalnote knyttet til mere end én enkeltsag, nedarver hver enkelt journalnote den opgaveklassifikation fra hver af de enkeltsager i forhold til hvilke noten er tilknyttet • sagsbehandlerinitialer – oprettes automatisk fra login • interessent id – nedarves automatisk fra sagen • et eller flere journalnoteobjekt id’er, fx CVR-nummer • journalarksnotetype* • notater (fritekst).

*jf. krav 3.409 Brugergenerering af journalarksnoter

356** 632

Side 137 af 198

Journalarksmodul

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.396 K Journalnoter fra andre it-systemer

Det er et krav, at journalarksmodulet kan modtage systemgenererede journalnoter fra andre it-systemer (fagsystemer)

357 358

3.397 K Systemgenerering af journalnoter

Det er et krav, at journalarksmodulet automatisk generer journalnoter ved:• sagsstyringsaktiviteter, fx skift i sagens status og sagsfaser.• registrering af dokumenter i sags- og dokumentarkivet.• modtagelse af systemgenererede journalnoter fra andre it-systemer (fagsystemer).

358 359

3.398 K Brugergenerering af journalnoter

Det er et krav, at brugeren ved brugergenererede journalnoter skal kunne angive notetypen ved at vælge fra fx en dropdown-liste.

359 360

3.399 K Journalnotetyper

Det er et krav, at journalnotetyper kan opsættes lokalt. Som default opsætning skal journalarkmodulet indeholde følgende journalnotetyper:• indkommet brev, underretningsskrivelse, ansøgning, anke, fax, webhenvendelse, e-mail, udgående brev, partshøring, dataindsamling, notat/dokument, vurdering, henvendelsesreferat, telefonreferat, samtalereferat, besøgsreferat, mødereferat, erindringsnote, aftale og notat.

jf. krav 3.411 (Tilpasning af journalnotetyper)

360 361

3.400 K Tilpasning af journalnotetyper

Det er et krav, at en central og lokal administrator via en administrationsklient kan tilføje, ændre og deaktivere journalnotetyper

361 362

Side 138 af 198

Journalarksmodul

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.401 K Låsning af journalnote

Det er et krav, at en journalnote skal låses, hvorefter den ikke kan redigeres. Reglerne for, hvornår låsning skal ske, skal kunne opsættes lokalt hos Kunden.

362* 637

3.402 K Funktionalitet i teksteditor

Det er et krav, at teksteditoren i journalarket har tekstbehandlingsfunktionalitet, fx fed, understregning, indrykning, klip, indsæt, punktopstilling, stavekontrol, udskrivning samt kopiering af tekst.

363 364

3.403 K Indhold i journalark

Journalarket skal indeholde 3 typer information:• metadata, der refererer til dokumenter• noter med afsæt i sagsbehandlerens notatpligt, bl.a. telefonsamtaler, e-mailkontakt og personligt fremmøde• “sagsprocesoplysninger”, fx skift i sagsstatus, afslutningsdato

364 365

Side 139 af 198

Journalarksmodul

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.404 K Søgefunktionalitet til opstilling af journalark

Det er et krav, at journalarksmodulet skal indeholde en søgefunktionalitet hvormed brugeren udsøger indhold til opstilling af journalark, med følgende søgekriterier:• en enkelt sag (fx for en interessent)• på tværs af flere sager (fx flere enkeltsager for den enkelte interessent)Ovenstående skal kunne søges i kombination med:• indenfor datointerval• på opgaveklassifikation• i fritekst, til søgning i tekst i titelfeltet eller i notatfeltet

365** 633

3.405 K Rækkefølge og sortering af journalnoter

Det er et krav, at journalarket automatisk skal fremkomme i omvendt kronologisk rækkefølge efter dato. Metadata for journalnoter skal i øvrigt kunne anvendes som sorteringskriterier ved visning af journalarket.

Jf. krav 3.406 (Struktur for journalarksnoter)

366 367

3.406 K Fra journalark til detaljer i den enkelte journalnote eller dokument

Det er et krav, at sagsbehandleren skal kunne få vist detaljer om de enkelte journalnoter eller dokumenter, der sammenstilles i et journalark (fx ved at ”at folde teksten ud” i sin helhed).

367 368

3.407 K Link til dokument

Det er et krav, at journalarksmodulet skal oprette et link fra en journalnote til et dokument, så det kan åbnes direkte fra noten.

368 369

Side 140 af 198

Journalarksmodul

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.408 K Gemme journalark

Det er et krav, at et dannet journalark kan gemmes på den sag, der initierede søgningen i et fast, ikke-redigerbart format, så det fremgår, hvad der er søgt på og hvad, der var resultatet af søgningen.

369 370

3.409 K Udskrive journalark

Det er et krav, at et dannet journalark kan udskrives.

370 371

7.3.5 Visning og overblikDet er centralt for sagsbehandlerens samlede styring og håndtering af sager og dokumenter, at Løsningen understøtter behovet for overblik, blandt andet for at understøtte sagsbehandlerens mulighed for at monitorere hvad, der sker med ”mine sager” og hvor de befinder sig i den samlede sagsproces. Et sikkert sagsoverblik giver sagsbehandleren et bedre udgangspunkt i forhold til at kunne fokusere på aktuelle opgaver og overskue disse. Hvis ikke Løsningen tilfredsstiller brugerne på dette område, så opleves Løsningen som tung og kompliceret, og det nedsætter effektiviteten og den samlede produktivitet. Derfor er det vigtigt, at brugeren oplever visningen af et søgeresultat som enkel og overskuelig. Hvad der er enkelt og overskueligt, kan dog variere afhængigt af brugssituation og behov.

Side 141 af 198

Visning og overblik

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.410 K Visning af søgeresultat efter relevans

Det er et krav, at søgeresultatet kan vises efter relevans. Brugeren skal kunne angive, om visningen skal baseres på relevans. Relevante hits vises efter givne kriterier for relevans. Kravet kan fx imødekommes ved, at brugeren selv kan udpege relevante felter og relevant feltsortering til visning i det aktuelle søgeresultat. Prioritering af relevans kan eksempelvis være 1) hits i udvalgte felter, 2) antal hit, 3) hits dokumenttekst eller andet.

251 252

3.411 K Dannelse af sagsoverblik på grundlag af relevante søgekriterier

Det er et krav, at sagsoverblik kan dannes på grundlag af relevante søgekriterier baseret på sagens metadata og tilknyttede dokumenter eller interessenter.

Søgning er kravspecificeret i afsnit 7.2.3, Søgning og fremfinding

252** 714

3.412 K Præsentation af søgeresultater

Det er et krav, at Løsningen kan præsentere de fundne søgeresultater på en overskuelig og intuitiv måde, således at brugeren hurtigt kan danne sig et overblik. Løsningen skal kunne præsentere søgeresultater med metadata i eksempelvis en listestruktur og en stifinder-lignende struktur.

253 254

3.413 K Beskrivelse af funktionalitet til visning efter relevans samt præsentation


Info. 57*

780

Side 142 af 198

Visning og overblik

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.414 K Sagsoverblik - differentiering af sagsoverblik efter sagstype

Det er et krav, at sagsoverblik kan differentieres efter sagstype, så der kan defineres forskellig visning af fx en projektsag og en personsag.

254 255

3.415 K Sagsoverblik – overblik over en afgrænset gruppe af sager

Det er et krav, at der kan dannes sagsoverblik over en afgrænset gruppe af sager. Sagerne kan fx vedrøre en given interessent, et udvalgt emne eller de kan være samlet i et projekt eller en samlesag.

Gruppering af sager er kravspecificeret i forbindelse med afsnit 7.1.2, Behandler sag.

255** 715

3.416 K Sagsoverblik - overblik over en afgrænset gruppe af dokumenter

Det er et krav, at der kan dannes overblik over en afgrænset gruppe af dokumenter. Dokumenterne kan fx være samhørende mails i en mail korrespondance, breve med tilhørende besvarelser, eller alle versioner af et dokument.

256 257

3.417 K Faste søgninger af sager

Det er et krav, at der tilbydes faste søgninger af sager som fx åbne sager, aktive sager, ’dagens post’, ubehandlede dokumenter eller andre.

257 258

3.418 K Tilgang til samlemapper

Det er et krav, at Løsningen giver tilgang til relevante samlemapper. Det kan fx være fra favoritmapper, overbliksbilleder, mv.

258 259

Side 143 af 198

Visning og overblik

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.419 K Fremhævelse af vigtige informationer i overblik

Det er et krav, at overblikket vises, så vigtige informationer tydeligt fremtræder. Kravet kan evt. imødekommes ved, at fx sager, der er ved at overskride behandlingsfrist og aktuelle opgaver fremhæves visuelt.

259 260

3.420 K Fremhævelse af aktuelle sager i sagsoverblik

Det er et krav, at sagsoverblikket kan fremhæve aktive sager frem for passive sager og åbne frem for lukkede sager, så det fremgår tydeligt i sagsoverblikket, hvilke sager der er aktuelle for brugeren. Dette kan fx imødekommes ved, at passive eller lukkede sager gråmarkeres, eller helt kan fjernes fra sagsoverblikket efter valg fra brugeren.

(Sagsstatus er kravspecificeret i afsnit 6.2 forretningsobjektet Sag).

260* 834

3.421 K Illustration af sagsfase/sagstilstand i sagsoverblik

Det er et krav, at sagsoverblikket kan illustrere sagsfase/sagstilstand, så det fremgår, om sagen er modtaget/ny, under behandling, venter, i høring, til godkendelse eller andre typer status, der bliver defineret i forbindelse med udviklingen af Løsningen, herunder implementeringen af workflows. Dette kan fx imødekommes ved, at en udvalgt fase fremhæves visuelt.

261** 667

Side 144 af 198

Visning og overblik

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.422 O Visuelt Sagsforløb

Løsningen skal give mulighed for at følge sagens forløb visuelt på et procesdiagram. Det betyder, at det skal fremgå af procesdiagrammet, der findes for de enkelte processer, på hvilket trin den aktuelle sag befinder sig. Herudover skal systemet give mulighed for via procesdiagrammet at kunne klikke sig frem til de QA procedurer, der gælder for de enkelte procestrin, og hvilke hjælpeværktøjer i form af rutediagrammer og brevskabeloner der skal anvendes.

Se også: Danner sagsprocesoverblik, afsnit 7.1.10

- 484

3.423 K Overblik over historik på en sag

Det er et krav, at brugeren kan danne overblik over, hvem der har gjort, hvad ved en sag. Fx hvem, der har modtaget sagen, behandlet sagen, sendt sagen i høring etc.

262 263

3.424 K Overblik over sagsansvarlige på en sag

Det er et krav, at brugeren kan danne overblik over, hvem der har haft ansvar for en sag, og hvornår et ansvar evt. er ændret fra en sagsbehandler til en anden

263 264

3.425 K Hurtig visning af en sags dokumenter

Det er et krav, at sagens dokumenter kan vises i hurtig visning fx vha. en læserude, ligesom det skal være muligt at vende tilbage til det sted i sagsoversigten, der var det oprindelige udgangspunkt.

264 265

3.426 K Overblik i forbindelse med skift mellem flere sager/dokumenter

Det er et krav, at brugeren skal kunne arbejde med flere sager ad gangen dvs. let kunne skifte mellem flere sager/dokumenter, der hver især fastholder den visning, der er valgt.

265 266

Side 145 af 198

Visning og overblik

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.427 K Mulighed for individuel visning af søgeresultater

Det er et krav, at visning af søgeresultaterne skal ske i forhold til brugervenlighed og intuitiv forståelse, herunder mulighed for individuel opsætning af resultatlister, let adgang til at skifte mellem resultatlister og fremsøgte sager/dokumenter og mulighed for at ”bladre” i resultatlister og bearbejde de fremkomne søgeresultater.

266 267

3.428 K Visning af dokumenter inddelt i undergrupperinger

Det er et krav, at såfremt den fremfundne sag har mange tilknyttede dokumenter (fx flere hundrede) og disse dokumenter er inddelt i undergrupperinger, skal søgeresultatet afspejle de strukturer, dokumenterne er lagret efter. Brugeren kan således danne sig et overblik over sagens omfang. Fra resultatlisten skal det samtidig være nemt at bladre sig ned gennem sagen.

267 668

3.429 K Beskrivelse af visning med dokumenter inddelt i undergrupperinger


Info. 58*

781

Side 146 af 198

Visning og overblik

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.430 K Udarbejdelse af rapport - generering af rapporter

Det er et krav, at Løsningen i vid udstrækning stiller et rapportgenereringsværktøj til rådighed, således at det er muligt at fremstille en række forskellige rapporter eksempelvis afhængig af brugerprofilen. Det forventes således, at der for eksempel for en ledelsesprofil kan genereres rapporter på baggrund af en række parametre, eller der for en given sagsbehandler kan genereres en postliste på baggrund af eksempelvis Kundens postproduktion.

268 627

3.431 K Udarbejdelse af rapport - opsætning af rapporter

Det er et krav, at brugeren selv kan opsætte rapporter, herunder faste, eksempelvis baseret på fristovervågning eller ad hoc.

269 270

3.432 K Beskrivelse af udarbejdelse af rapport - standardrapporter


Info. 59*

782

3.433 K Udarbejdelse af rapport – eksport til ODF, OOXML, Excel og Word

Det er et krav, at Løsningen giver brugeren mulighed for at eksportere til ODF, OOXML, Excel og Word.

270 271

7.3.6 Rapporter og statistikker

Side 147 af 198

Rapporter og statistikker

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.434 O Udtræk af tilfældigt udvalgte sager eller interessenter

Det skal være muligt manuelt og automatisk at igangsætte udtræk af sager eller interessenter, f.eks. til stikprøve, kvalitetskontrol eller kundetilfredshedsundersøgelse.Det skal kunne defineres lokalt:- hvad der er forudsætningerne for populationen/puljen af sager/interessenter, der udtrækkes fra (fx sagstype, sagsstatus, tidsperiode, herunder kriterierne for/hændelserne der har betydning for hvornår en sag har en given sagsstatus).- hvor mange sager eller interessenter, der udtrækkes fra puljen enten som antal eller udtrykt som en andel af det samlede antal sager/interessenter i puljen. Andelen af de forskellige sagstyper i den samlede sagspulje skal afspejles i stikprøven.- om sager/interessenter, der opfylder kriterierne for at blive udtrukket flere gange i perioden skal tælle med én eller flere gange.

- 687

3.435 O Automatisk sagsfordeling

Det skal være muligt, at sager fordeles automatisk på baggrund af forud definerede kriterier. Kriterierne skal let kunne konfigureres og ændres.

- 569

3.436 O Historisk overblikssøgning

Det er et krav, at det er muligt at lave en ”historisk øjeblikssøgning”, dvs. en søgning på et givent (historisk) tidspunkt.

- 625

Side 148 af 198

8. Ikke-funktionelle kravDe ikke-funktionelle krav til Løsningen omhandler alle de krav, som ikke direkte beskriver forretningsfunktionalitet.

8.1 Arkitektur og miljøerKundens nuværende IT-miljø er beskrevet i bilag 2. Kundens forventning til den fremtidige arkitektur i Løsningen er beskrevet i afsnit 2.1 Løsningen og dens omgivelser. Herunder findes krav til arkitekturen for Løsningen.

Arkitektur og miljøer

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.437 K Anvendelse af målarkitektur i udvikling af Løsningen

Leverandøren skal redegøre for, i hvor høj grad målarkitekturen respekteres i den tilbudte Løsning. Dette drejer sig især om:• Løsningens lag- og komponentopbygning efter principper om service orienteret arkitektur (SOA).• Opbygning af Løsningens centrale database.• Mulighed for til- og frakobling af interne og eksterne services via Løsningens integrationsplatform.• Mulighed for at opsætte og konfigurere Opslag samt E-blanketter, Tabeller og Rapporter uden behov for programmering.

Se Bilag 2 Kundens it-miljø og afsnit 2.1 Løsningen og dens omgivelser

- 619

Side 149 af 198

Arkitektur og miljøer

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.438 K Redegørelse for anvendelse af standardsystemer og –komponenter i Løsningen

Leverandøren skal redegøre for, i hvor høj grad den tilbudte Løsning er baseret på standardsystemer og –komponenter. Der skelnes i den forbindelse mellem fire kategorier af indgående elementer, og tilbudsgiver skal redegøre for, hvor stor en del af den samlede Løsning, hver kategori udgør:1. Standardprodukter, som er gennemprøvede og underkastet en leverandørs versionsstyring, og som har mindst 1000 kørende referencer (f.eks. softwareprodukter fra Microsoft eller Oracle).2. Standardkomponenter, som er gennemprøvede og har mindst 10 kørende referencer.3. Komponenter, som allerede er udviklet og har mindst én kørende reference.4. Nyudviklede komponenter.

- 620

8.2 DatamodelNedenstående tager udgangspunkt i Kundens datamodel for Løsningen (se Underbilag 3.3). Datamodellen er designet sådan, at en lang række arbejdsgange fortsat vil kunne være automatiserede. Datamodellen er endvidere central i at sikre, at løsningen lever op til følgende forretningsmæssige mål:

Alle informationer og dokumenter vedrørende alle sager, skal lagres samme sted og i høj grad gøre brug af datagenbrug, således at de samme data kun skal indtastes én gang undervejs i sagsbehandlingen.

Systemet skal indeholde tværgående søgefunktionalitet, der gør det muligt at fremfinde dokumenter og sager på en let og effektiv måde, og hvor det er transparent for brugeren, hvilken service/system/database der leverer informationerne.

Det er derfor meget vigtigt, at logikken i datamodellen respekteres.

Side 150 af 198

Side 151 af 198

Datamodel

Krav

Kravtype


PVS ID

3.439 MK Datamodel - Fysisk database følger logisk datamodel

Logikken i datamodellen skal følges ved design af den fysiske database.

Underbilag 3.3 Datamodel

- 616

3.440 K Redegørelse – Logisk datamodel

Leverandøren skal redegøre for, hvilke dele af den logiske datamodel, der ikke vil kunne følges.

- 839

3.441 K Datamodel - Validering af datafangst

Datatyper (tekst, tal postnummer osv.) skal så vidt muligt valideres ved datafangst, så brugere bremses i at fodre løsningen med invalide data.

- 617

3.442 K Beskrivelse af validering af datafangst


- 840

8.3 Konvertering af dataKunden har haft elektronisk understøttelse af sine processer i snart 15 år, og der er løbende sket en indskanning af dokumenter i Kundens eksisterende systemer.Da Kunden udsteder rettigheder, der kan gælde i mange år, og sagsbehandlingen ofte tager udgangspunkt i behandlingen og eksistensen af tidligere sager, er det af afgørende betydning, at alle data og dokumenter er tilgængelige i Løsningen.

Konvertering af data

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.443 K Konvertering af data

Kunden laver udtræk af data fra de eksisterende systemer til en mellemdatabase.Det er et krav, at Leverandøren konverterer og indsætter disse data i Løsningen.

842

Side 152 af 198

Side 153 af 198

8.4 StandarderStandarder

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.444 MK UTF-8 tegnsæt

Det er et krav, at tegnsættet for Løsningens database skal være UTF-8. Det nuværende tegnsæt for databasen er ISO-8859-1, og eksisterende data skal konverteres til UTF-8. Løsningen skal, såfremt det ikke anvender UTF-8 som tegnsæt, kunne konvertere til og fra UTF-8 uden tab.

- 2

3.445 K Datastandarder for informations udveksling

Det er et krav, at Løsningen implementerer de nyeste versioner af FESD grænseflade standarderne

FESD Datafølgeseddel FESD Sikker epostløsning FESD Udvekslingspakke FESD Grænseflade til CMS-løsninger FESD Generisk Integrationsmodel FESD GIS-integrationsmodel

389** 643

3.446 K Datastandarder for specifikke it-services

Det er et krav, at Løsningen implementerer de nyeste versioner af FESD modul standarderne

FESD Ledelsesinformation FESD Skanningsmodul

390** 644

3.447 K eDag3

Det er et krav, at Løsningen skal kunne understøtte eDag3 krav.

- 490

3.448 K eDag4

Det er et krav, at Løsningen skal kunne understøtte eDag4 krav.

- 491

Side 154 af 198

Standarder

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.449 K Understøttelse af DKAL

Leverandøren skal levere en løsning, som kan understøtte DKALSe:http://modernisering.dk/fileadmin/user_upload/documents/Projekter/Dokumentboks_NemSMS/Kravspecifikation_DKAL.pdfog evt.:http://modernisering.dk/fileadmin/user_upload/documents/Projekter/Dokumentboks_NemSMS/Snitfladebeskrivelser__med_aendringslog_/Bilag_A5_-_REST_-_HTTP_returkoder_og_fejlkoder_5_m_aendringsmarkering.pdf

- 492

8.5 Struktur, forandringsparathed og platformDette afsnit specificerer krav til den strukturelle opbygning af den tilbudte løsning og derigennem den grad af forandringsparathed, som løsningen skal have, og kravene til standarder for service-interfaces og til fleksibilitet over for den teknologiske platform, som komponenten skal afvikles på.Kravene til platform er begrundet i, at løsningen skal være forberedt til at kunne skifte afviklingsplatform, hvis organisationsændringer kræver det.

Struktur, forandringsparathed og platform

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.450 K Microflow

Det er et krav, at Løsningen understøtter korte transaktionsorienterede processer (microflows), der er kendetegnet ved at involvere én bruger og én eller flere services.

375 376

Side 155 af 198

http://modernisering.dk/fileadmin/user_upload/documents/Projekter/Dokumentboks_NemSMS/Snitfladebeskrivelser__med_aendringslog_/Bilag_A5_-_REST_-_HTTP_returkoder_og_fejlkoder_5_m_aendringsmarkering.pdf



http://modernisering.dk/fileadmin/user_upload/documents/Projekter/Dokumentboks_NemSMS/Kravspecifikation_DKAL.pdf




Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.451 K Operationer i et microflow

Det er et krav, at Løsningen understøtter, at et helt flow (fx en realisering af en usecase) som minimum kan:• definere start og slut for en arbejdsgang• foretage valg ud fra dataværdier, der har indflydelse på en arbejdsgang• opsætte rækkefølge af aktiviteter i en arbejdsgang, inklusive forgreninger og sammenføjninger• opsætte tidsfrister for aktiviteter og delarbejdsgang• abonnere på adviser• håndtere en samlet dynamisk kontekst• håndtere formidling af kontekst til og fra servicekald• håndtere flow / transformation af data mellem services• håndtere fejl og afvigelser, enten gennem advisering af personaktører eller gennem kompenserende transaktioner

376 377

3.452 K Sammensatte it-services

Det er et krav, at Løsningen gør det muligt at sammensætte Løsningens it-services til brug i specifikke arbejdssituationer.

377 378

3.453 K Tilpasse og sammensætte services

Det er et krav, at Løsningen kan sammensætte, aggregere, transformere og filtrere informationer fra flere services til brug for en specifik arbejdsaktivitet.

378 379

Side 156 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.454 K Beskrivelse af sammenhængende model for microflows

Leverandøren skal kort redegøre for, hvorledes Løsningen opfylder behov beskrevet i krav 3.450 – 3.453.

Info. 71*

783

3.455 K Integration af microflows i anden orkestrering

Løsningen skal kunne udstille et procesinterface, således at microflows defineret i Løsningen kan indgå som sub-aktivitet i andre arbejdsgange. Dette procesinterface skal følge den internationalt førende standard for procesdefinitioner BPEL.

379 380

3.456 K Versionshåndtering af services i Løsningen

Det er et krav, at versionshåndtering understøttes i Løsningen, herunder ikke mindst undtagelser samt versionshåndteringens indflydelse på søgning og navigation.

381 382

3.457 K Serviceinfrastruktur faciliteter

Det er et krav, at Løsningen understøtter følgende faciliteter til en service-infrastruktur:• Overvågning og monitorering• Routing• Logning

382 383

3.4582

K Beskrivelse af serviceinfrastruktur

Leverandøren skal redegøre for, hvorledes Løsningen opfylder behov beskrevet i krav 3.456 – 3.457.

Info. 72*

784

3.459 K Serviceinfrastruktur faciliteter

Det er et krav, at Løsningen understøtter følgende faciliteter til en service-infrastruktur:• Web-service publicering• Hændelseshåndtering

384 385

Side 157 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.460 K Serviceinterfaces skal kunne udstilles

Det er et krav, at serviceinterfaces, der giver adgang til it-services i Løsningen, udstilles i et katalog, således at der på ethvert tidspunkt kan skabes overblik over hvilke services, der er tilgængelige.

385 386

3.461 K UDDI standarden

Det er et krav, at servicekataloget, hvor det giver mening, kan overholde OIO UDDI - Universal Description Discovery & Integration. OIO UDDI 1.1 definerer en samlet datamodel og søge-arkitektur for serviceregistre i den offentlige sektor.

386** 689

3.462I

K Beskrivelse af serviceinfrastruktur 2

Leverandøren skal redegøre for, hvorledes Løsningen opfylder behov beskrevet i krav 3.459 – 3.461.

Info. 73*

785

3.463 K Flytbarhed

Det er et krav, at Løsningen er flytbar mellem samme afviklingsplatforme fra en geografisk location til en anden, og fra en afviklingsplatform til en anden.

387 388

3.464 K Beskrivelse af flytbarhed

Leverandøren skal redegøre for, hvilke afviklingsplatforme, Løsningen kan leveres på, samt hvorledes Løsningen kan flyttes som beskrevet i krav 3.463.

Info. 74*

786

8.6 IntegrationKundens forretning er meget afhængig af integrationer med, samt importer fra og eksporter til andre systemer. Disse andre systemer befinder sig lokalt hos Kunden og hos udenlandske myndigheder. Dette afsnit giver en oversigt over krav til muligheden for integrationer, importer og eksporter til og fra Løsningen.

Side 158 af 198

Side 159 af 198

8.6.1 Integration generelt

Integration generelt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.465 MK Integration generelt

Det er et krav, at Løsningen stiller et interface til rådighed, der gør det muligt at udtrække sagsdata og dokumenter til f.eks. en applikation eller en webservice. Udtrækket skal kunne initieres af ændringer i data i Løsningen.

Interfacet skal ligeledes gøre det muligt at indsætte sagsdata og dokumenter, der er leveret af f.eks. en applikation eller en webservice

- 562

3.466 MK Adgang til brugergrænseflade og funktionaliteter fra eksterne fagsystemer, applikationer eller services

Det er et krav, at Løsningen stiller et veldokumenteret interface til rådighed, der gør det muligt at tilgå Løsningens data og funktionalitet fra eksterne fagsystemer, applikationer eller services.

Kunden forventer således selv at kunne udvikle omkringliggende services, som både benytter sig af Løsningens data, manipulerer data, tilføjer data og påvirker fx hændelser eller workflows i Løsningen.

- 624

Side 160 af 198

Integration generelt

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.467 K Beskrivelse af adgang til brugergrænseflader og funktionaliteter fra eksterne fagsystemer, applikationer eller services

Leverandøren skal beskrive, i hvilket omfang Løsningen giver adgang som beskrevet i krav 3.466 Beskrivelsen skal omfatte eventuelle områder, hvor det ikke er muligt.

- 806

3.468 K Sikkerhed ved opslag via fagsystem

Det er et krav, at brugerne ved opslag fra fagsystem, og hvis denne ikke er logget ind i Løsningen (og ikke timed-out), skal møde et login skærmbillede inden visning af opslag.

- 539

3.469 MK Dokumentserver webservice

Det er et krav, at det er muligt at tilgå Løsningens dokumentserver, således at dokumenter kan hentes til eller lagres fra systemer uden for Løsningen. Løsningen skal stille et veldefineret interface til rådighed, som gør det muligt at hente og indsætte dokumenter.

- 557

8.6.2 Import af klassesystemerPatenter, brugsmodeller, varemærker, design og lignende rettigheder udstedes for bestemte klasser. Et varemærke udstedes således kun for specifikke klasser, der dækker visse grupper af varer. Klassesystemerne er resultater af internationale forhandlinger og opdateres med jævne mellemrum og indeholder både hovedklasser og underklasser. I rettighedssager skal brugerne kunne vælge/identificere den korrekte version af klassesystemet samt den/de korrekte klasser for sagen. Derfor er der nedenfor stillet krav om mulighed for import til Løsningen af klassesystemer. Nedenfor er en liste over de klassesystmer, som Kunden anvender:

IPC (International Patent Classification) er det internationale klassifikationssystem, som bruges til klassificering af alle patenter og brugsmodeller.

Side 161 af 198

Nice-klassifikationen er den internationale varemærkeklassifikation. Locarno-klassifikationen er den internationale designklassifikation. Vienna-klassifikationen er den internationale klassifikation for figurmærker.

De fulde klassifikationer kan ses via Kundens hjemmeside: http://www.dkpto.dk/vaerktoejer/klassifikationer.aspx.

Pr. 1. januar 2013 træder CPC (Cooperative Patent Classification) i kraft. CPC er et klassesystem fælles mellem Europa og USA, som skal bruges til klassificering af alle patenter og brugsmodeller. Der er ikke vedlagt bilag om import af denne type af klassifikation. Yderligere information om CPC kan ses her: www.cpcinfo.org.

Import af klassesystemer

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.470 MK Import af nye versioner af internationale klassesystemer

Det er et krav, at det skal være muligt at importere nye versioner af internationale klassesystemer som fx IPC, Nice, Locarno, Vienna og CPC til Løsningen.

Løsningen skal stille et interface til rådighed, som gør det muligt at indsætte data vedrørende klassifikationssystemerne, fx en webservice.

Klassifikationerne kan findes via dette link: http://www.dkpto.dk/vaerktoejer/klassifikationer.aspx

- 477

8.6.3 Import af MP varemærkedata fra WIPOInternationale varemærker (MP) er varemærker, der er ansøgt via Madrid-protokollen. Madrid-protokollen er et internationalt system, hvor man på basis af én varemærkeansøgning, kan designere en række lande, herunder Danmark, og derigennem få sit varemærke registreret i Danmark. Ordningen administreres af WIPO. Kunden skal til enhver tid kunne se, hvilke rettigheder, der er gyldige i Danmark, og derfor skal Kunden kunne foretage import til Løsningen af informationer om Madrid-protokol varemærker gældende i Danmark.

Side 162 af 198

http://www.dkpto.dk/vaerktoejer/klassifikationer.aspx



http://www.cpcinfo.org/


Import af MP varemærkedata fra WIPO

Krav

Kravtype


PVS ID

3.471 MK Import af MP varemærkedata fra WIPO

Det er et krav, at det er muligt at importere data og dokumenter vedrørende MP varemærker gældende i Danmark fra WIPO til Løsningen. Løsningen skal stille et veldefineret interface til rådighed, som gør det muligt at indsætte sagsdata og billeder, fx en webservice.

Kunden benytter dette interface til selv at udvikle en ETL kørsel eller lignende.

Se

Underbilag 3.4

- 471

8.6.4 Eksport af MP varemærkedata til WIPO Madrid-protokollen er et internationalt system, hvor man på basis af én varemærkeansøgning til WIPO, kan designere en række lande herunder Danmark og herigennem få sit varemærke registreret i Danmark. Ordningen administreres af WIPO. Kunden eksporterer data og dokumenter vedrørende danske Madrid-protokol varemærker til WIPO. Til denne eksport benyttes MECA, som står for Madrid Electronic CommunicAtions. Dette er en standard for informationsudveksling fastlagt af WIPO, som tager sigte på udveksling af meddelelser vedrørende varemærker udstedt efter Madrid-protokollen.

Eksport af MP varemærkedata til WIPO

Krav Kravtype


PVS ID

3.472 MK Eksport af MP varemærkedata til WIPO

Det er et krav, at det er muligt at eksportere data og dokumenter vedrørende MP varemærker fra Løsningen til WIPO. Løsningen skal stille et interface til rådighed, som gør det muligt at udtrække sagsdata, fx en webservice. Kunden benytter dette interface til selv at udvikle en ETL kørsel eller lignende.

Se Underbilag 3.4

- 475

Side 163 af 198

8.6.5 Import af IR varemærkedata fra WIPO Når en udenlandsk varemærkeindehaver efter Madrid-protokollen vælger at designere den Europæiske Union som helhed via en international ansøgning, gælder den også i Danmark. Kunden skal til enhver tid kunne se, hvilke rettigheder, der er gyldige i Danmark, og derfor skal informationer om disse specifikke typer af internationalt registrerede (IR) varemærker importeres til Løsningen.

Import af IR varemærkedata fra WIPO

Krav Kravtype


PVS ID

3.473 MK Import af IR varemærkedata fra WIPO

Det er et krav, at det er muligt at importere data og dokumenter for IR varemærker gældende i Danmark fra WIPO til Løsningen. Løsningen skal stille et interface til rådighed, som gør det muligt at indsætte sagsdata, fx en webservice. Kunden benytter dette interface til selv at udvikle en ETL kørsel eller lignende.

Se Underbilag 3.4

- 472

8.6.6 Eksport af prioritetsbeviser til WIPOPrioritetsbeviser bruges af ansøgere til patenter til at bevise, hvornår patentet første gang blev ansøgt, også kaldet prioritetsdatoen. Kunden tilbyder mod betaling patentansøgere at deponere elektroniske prioritetsdokumenter hos WIPO via WIPO’s Digital Access Service (DAS), som er et elektronisk bibliotek for prioritetsdokumenter. Når patentansøgere ønsker at videreføre patenter i andre lande, kan andre patentmyndigheder hente prioritetsbeviset direkte i WIPOs DAS uden at ansøger behøver at sende papirkopier.

Side 164 af 198

Eksport af prioritetsbeviser til WIPO

Krav Kravtype


PVS ID

3.474 MK Eksport af prioritetsbeviser til WIPO

Det er et krav, at det er muligt at eksportere data og dokumenter vedrørende prioritetsbeviser fra Løsningen til WIPO. Løsningen skal stille et interface til rådighed, som gør det muligt at udtrække sagsdata, fx en webservice.


Se Underbilag 3.4

- 474

8.6.7 Eksport af danske patent- og brugsmodeldata til EPO Kunden leverer ugentligt data og dokumenter til EPO for at gøre information om danske patenter og brugsmodeller tilgængelige for tredjemand både i EPO’s databaser og de kommercielle databaser som EPO leverer oplysningerne til.

Side 165 af 198

Eksport af danske patent- og brugsmodeldata til EPO

Krav Kravtype


PVS ID

3.475 MK Eksport af danske patent- og brugsmodeldata til EPO

Det er et krav, at det er muligt at udtrække data og dokumenter fra Løsningen til brug for eksport til EPO. Løsningen skal stille et veldefineret interface til rådighed, som gør det muligt at udtrække sagsdata, fx en webservice. Kunden benytter dette interface til selv at udvikle en ETL kørsel eller lignende.

Se Underbilag 3.4

- 469

8.6.8 Eksport af bortfaldsliste til EPOMan kan ansøge om patent hos det europæiske patentkontor (EPO). På indleveringstidspunktet angiver patentansøger, om patentet ønskes valideret i Danmark. Hvis EPO udsteder patentet, skal patentansøger indlevere en oversættelse og betale et publiceringsgebyr til Kunden for at patentet kan blive gældende i Danmark. Fra godkendelsestidspunktet betaler patentindehaveren årsgebyr til Kunden. Årsgebyret deles ligeligt mellem Kunden og EPO. Kunden skal meddele EPO, hvilke udstedte EP patenter, der ikke er gyldige i Danmark som følge af manglende oversættelse/publiceringsgebyr. Det drejer sig om ca. 40.000 sager om året. Kunden skal også meddele EPO, når et EP patent med gyldighed i Danmark bortfalder, fordi der ikke længere betales årsgebyr. På grund af delingen af årsgebyret mellem EPO og Kunden er det af stor økonomisk betydning, at der er styr på disse data.

Eksport af bortfaldsliste til EPO

Krav Kravtype


PVS ID

3.476 K Eksport af bortfaldliste til EPO

Der er et krav, at der kan etableres et udtræk, som giver EPO oplysninger om bortfald af europæiske patenter, der er validerede i Danmark.

Se Underbilag 3.4

- 540

8.6.9 Import af EP patentdata fra EPO

Side 166 af 198

Det europæiske patentkontor, EPO, behandler og udsteder patenter, som kan få gyldighed i Danmark. Denne type patenter kaldes EP patenter. Kunden skal til enhver tid kunne fastslå status for EP patenter, idet Kunden opkræver gebyrer for disse patenter. Til brug herfor skal Kunden kunne foretage import til Løsningen af informationer om EP patenter, der er designeret i Danmark. Bemærk, at det er betydelige mængder af sager, der importeres hver uge. Se nærmere i underbilaget.

Import af EP patentdata fra EPO

Krav Kravtype


PVS ID

3.477 MK Import af EP patentdata fra EPO

Det er et krav, at det skal være muligt at importere EP patent- og dokumentdata med gyldighed i Danmark fra EPO til Løsningen. Løsningen skal stille et veldefineret interface til rådighed, som gør det muligt at indsætte sagsdata, fx en webservice.


Se Underbilag 3.4

- 470

8.6.10 Import af EU varemærkedata fra OHIM CTM står for Community Trademark og er et varemærke, der gælder for hele EU. CTM administreres af EU's kontor for varemærker og design, OHIM. Kunden skal til enhver tid kunne se, hvilke rettigheder, der er gyldige i Danmark, og derfor skal informationer om CTM varemærker importeres til Løsningen.

Side 167 af 198

Import af EU varemærkedata fra OHIM

Krav Kravtype


PVS ID

3.478 MK Import af EU varemærkedata fra OHIM

Det er et krav, at det er muligt at importere data og dokumenter vedrørende EU varemærker gældende i Danmark fra OHIM til Løsningen. Løsningen skal stille et interface til rådighed, som gør det muligt at indsætte data og dokumenter, fx en webservice.


Se Underbilag 3.4

- 473

Side 168 af 198

8.6.11 Eksport af varemærkedata til TMViewTMView er en fælleseuropæisk varemærkeportal, der giver mulighed for søgning i de deltagende landes varemærkedata. TMView administreres af OHIM (EU's varemærke- og designkontor), der har udviklet webportalen og webgrænsefladen. Kunden har udviklet eget data- og dokumentudtræk samt egen webservice. Kunden bliver betalt for deltagelse i TMView baseret på en række kriterier såsom webservice oppetid, webservice svartid, upload frekvens.

Eksport af varemærkedata til TMView

Krav Kravtype


PVS ID

3.479 MK Eksport af varemærkedata til TMView

Det er et krav, at det er muligt at eksportere data og dokumenter fra Løsningen til varemærkeportalen TMView. Løsningen skal stille et interface til rådighed, som gør det muligt at udtrække sagsdata og figurer, fx en webservice.


Se Underbilag 3.4

- 476

8.6.12 Import fra E-ansøgningE-ansøgning er Kundens webbaserede system til indlevering af rettighedsansøgninger.

Side 169 af 198

Import fra E-ansøgning

Krav Kravtype


PVS ID

3.480 MK Import fra E-ansøgning

Det er et krav, at Løsningen gør det muligt at automatisere oprettelsen af rettighedsansøgninger, som er indkommet via webbaseret E-ansøgning. Oprettelsen af rettighedsansøgning omfatter oprettelse af sag og interessenter og tilknytning af data og dokumenter.

Importen skal ske via et veldefineret interface til Løsningen, fx en webservice.


- 463

8.6.13 Import fra EOLFEOLF (Epoline Online Filing) er et system til elektronisk indlevering af patentansøgninger. Systemet bruges både til indlevering af europæiske ansøgninger, men også til indlevering af danske nationale patentansøgninger til Kunden. EOLF er integreret med Epoline, som er en samling webprogrammer og tjenester, der bl.a. gør det muligt at indlevere patentansøgninger online til EPO.

Side 170 af 198

Import fra EOLF

Krav Kravtype


PVS ID

3.481 MK Import fra EOLF

Det er et krav, at Løsningen gør det muligt at automatisere oprettelsen af rettighedsansøgninger, som er indkommet via EOLF klient. Oprettelsen af rettighedsansøgning omfatter oprettelse af sag og interessenter og tilknytning af data og dokumenter.

Importen skal ske via et veldefineret interface, fx en webservice.


- 465

8.6.14 Eksport til CRMKunden anvender customer relationship management (CRM) systemet SuperOffice i sin Salg- og Marketings afdeling. CRM-systemet bruges til Kundens styring af salgsaktiviteter og kundekontakt.

Eksport til CRM

Krav Kravtype


PVS ID

3.482 MK Eksport til CRM

Det er et krav, at det er muligt at udtrække interessentoplysninger til brug for eksport til Kundens CRM-system. Løsningen skal stille et veldefineret interface til rådighed, der gør det muligt at udtrække disse oplysninger.

Kunden vil med udgangspunkt i dette interface selv udvikle synkronisering fra Løsningens interessenter til CRM.

- 458

Side 171 af 198

Eksport til CRM

Krav Kravtype


PVS ID

3.483 K Beskrivelse af integration med CRM

Leverandøren bedes redegøre for, om der findes andre muligheder for integration med CRM, end den der er specificeret i krav 3.483.

- 807

8.6.15 Integration til økonomisystemDet er helt centralt for Kundens lovfæstede opgavevaretagelse, der bl.a. omfatter udstedelse af rettigheder og salg af serviceydelser på markedsvilkår, at integrationen med Kundens økonomisystem fungerer. Rettidig betaling af gebyrer afgør således, om rettigheder opretholdes eller bortfalder, og manglende betaling af fakturerede serviceydelser skal kunne udløse rykker- og inkassoprocedurer. Kunden anvender pt. et specialtilpasset udgave af Navision Stat til al økonomi og bogholderi, der dog senest i forbindelse med implementeringen vil blive erstattet af en standard udgave. Eventuelle nødvendige tilpasninger, for at kunne styre sammenhængen mellem sag og økonomi vil blive håndtereret i mellemliggende opkrævnings- og faktureringsmodul. Det betyder, at faktureringsgrundlaget skal være til stede i Løsningen, og skal kunne sendes til økonomisystemet, hvor selve faktureringen sker. Endvidere skal Løsningen kunne modtage og igangsætte f.eks. hændelser på baggrund af input fra økonomisystemet.Dette er som ovenfor beskrevet særdeles vigtigt for Kunden, og vil blive tillagt særlig vægt ved tildelingen.

Integration til økonomisystem

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.484 MK Faktureringsgrundlag

Datagrundlag for fakturering og opkrævninger skal kunne stilles til rådighed for Kundes økonomisystem via en webservicegrænseflade.

- 560

Side 172 af 198

Integration til økonomisystem

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.485 MK Fakturavisning

Det er et krav, at Løsningen giver mulighed for, at man kan få vist en opkrævning/faktura/kreditnota fra økonomisystemet.

- 525

3.486 K Beskrivelse af mulighed for fakturavisning

Leverandøren skal beskrive, hvorledes Løsningen opfylder behovet beskrevet i krav 3.485

841

8.6.16 Eksport til PVSonlinePVSonline er kundens offentlige webbaserede database med offentligt tilgængelige ansøgninger og rettigheder samt tilhørende dokumenter.

Eksport til PVSonline

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.487 MK Eksport til PVSonline

Det er et krav, at dette register kan opdateres mindst en gang i døgnet med nye eller ændrede data, sager og dokumenter, via et veldefineret interface, fx en webservice.


- 457

8.6.17 Integrationsmønstre, kommunikationsstandarder, integritet, sikkerhed og pålidelighedI dette afsnit behandles integrationsmønstre og standarder for kommunikation samt integritet, transaktionssikkerhed og pålidelighed,

Side 173 af 198

I forbindelse med opgaver, der går på tværs af systemer, afdelinger og sektorer, er der behov for at udveksle forretningshændelser. Hændelseshåndtering understøtter publicering af og abonnement på hændelsesbeskeder. Håndteringen består i at modtage og på baggrund af aftaleinformation sikre, at hændelsen når interessenterne – interessenter vil typisk være personer eller procesinstanser (evt. procestrin). Denne udveksling skal håndteres af en generel hændelsesfordeler. Det er vigtigt, at hændelsesfordeleren kan være uafhængig af løsningerne. Løsningen skal kunne publicere og abonnere på hændelsesbeskeder

Integration – integrationsmønstre, kommunikationsstandarder, integritet, sikkerhed og pålidelighed

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.488 K Kommunikation inden for samme sikkerhedsdomæne

Det er et krav, at Løsningen kan anvende OIO REST standarder til at udveksle OIOXML mellem de interne it-services, der implementerer forretningstjenester.

394 395

3.489 K Kommunikation mellem forskellige sikkerhedsdomæner

Det er et krav, at Løsningen kan anvende følgende standarder

OIORASP eller sikker, pålidelig OIOREST FESD Hændelsesdrevet integration til

fagsystemer

395 396

3.490 K Abonnement på hændelser

Det er et krav, at Løsningen kan reagere på hændelser, fx skal man fra en sag kunne abonnere på en specifik hændelse eller en specifik type af hændelser. Hændelser kan være både interne og eksterne hændelser

396 397

Side 174 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.491 K Publicering af hændelser

Det er et krav, at et procestrin kan publicere en hændelse, fx skal en sagsændring kunne defineres til at aktivere en specifik hændelse.

397 398

3.492 K Publicering / abonnement

Det er et krav, at hændelseshåndtering omfatter et publicerings/abonnementssystem, hvor services kan udveksle hændelser dynamisk, og hvor brugeren adviseres

398 399

3.493 K Advisering via e-mail

Det er et krav, at hændelseshåndtering understøtter, at brugeren bliver adviseret om hændelser via Kundens e-mail system. (Indholdet i e-mails skal være i anonymiseret form).

399* 681

3.494 K Beskrivelse af hændelsestyper

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.491 – 3.494. Beskrivelsen skal indeholde, hvilke hændelsestyper, der kan håndteres, fx tilstandsændringer, objektændringer (oprettet, ændret, slettet), fejlafvigelser samt sammensatte og betingede hændelsestyper.

Info. 76*

788

Side 175 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.495 K Kontrol af intern dataintegritet

Det er et krav, at Løsningen kontrollerer dataintegritet mellem alle it-services, applikationer og komponenter, som er en del af tilbuddets Løsning gennem:• feltvalideringer ved input fra personaktører• validering af forretningsregler specificeret af forretningstjenesten• commit og rollback opdatering• skemavalideringer mellem løst koblede it-services• 2-phase-commit, hvis løsningen indeholder løst koblede data-services

392 393

3.496 K Kontrol af dataintegritet med eksterne services

Det er et krav, at Løsningen kontrollerer dataintegritet mellem alle it-services, som er eksterne til Løsningen leveret, gennem skemavalideringer mellem løst koblede it-services såvel ved fremsendelse af data, som ved modtagelse af data. Ved fejl i skemavalideringen skal den afsendende interne it-service eller den afsendende eksterne it-services give en meningsfuld fejlmeddelelse til afsenderen.

400 401

Side 176 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.497 K Automatisk routing af dataintegritetsfejl

Ved fejl i skemavalideringen skal den afsendende interne it-service eller den afsendende eksterne it-services give en meningsfuld fejlmeddelelse til afsenderen. Hvis denne afsender er en it-service, en applikation eller en komponent internt i Løsningen, skal fejlmeddelelse kunne routes tilbage til den personaktør, som har igangsat kommunikationen med et advis om, at der er fejl i de afgivne informationer, og hvad fejlene består i.Hvis afsenderen er ekstern til Løsningen, skal Løsningen kunne give afsenderen en OIOXML fejlmeddelelse, hvis kommunikationen er synkron, eller kunne udstille fejlmeddelelsen gennem OIOXML hændelse, hvis kommunikationen er asynkron.

402 403

Side 177 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.498 K Pålidelighed i kommunikationen med eksterne services

Det er et krav, at Løsningen automatisk kan genfremsende meddelelser, hvis kommunikationen mislykkes. Løsningen skal selv kunne definere genfremsendelsesmønstre:• Lineært (med faste tidsintervaller X antal gange)• Eksponentielt (2n stigende tidsinterval X antal gange)Det forventes, at den samme indstilling anvendes globalt i Løsningen.Løsningen skal sikre, at der ved modtagelse af forsendelser kun afleveres én gang.Disse krav gælder, hvad enten kommunikationen udføres synkront (afsender står stille og afventer svar) eller asynkront (afsender kan foretage sig andet, og modta-ger besked, når kommunikationen er gennemført eller fejlet).

403 404

Side 178 af 198

8.7 Sikkerhed og brugerstyringLøsningen indeholder forretningshemmeligheder, personfølsomme oplysninger samt klassificerede oplysninger, hvis videregivelse uden dertil indhentet bemyndigelse ville kunne forvolde Danmark eller Danmarks allierede alvorlig skade. Derfor er der et krav om sikker identifikation af brugerne og en sikker metode til autorisation og kontrol af brugerrettigheder. Dertil skal Løsningen i sin kommunikation med slutbrugerklienter og eksterne IT-services være i stand til at indgå i en sikkerhedsarkitektur, der beskytter mod fjendtlig indtrængen gennem anvendelse af demilitariserede zoner og firewalls.Aktørerne, der vil tilgå Løsningen, er beskrevet i afsnit 5. Det fremgår, at personaktørerne alle vil være placeret i det samme sikkerhedsdomæne. Personaktører eksternt til Løsningens sikkerhedsdomæne vil tilgå den via andre it-løsninger, dvs. gennem systemaktører, der integrerer med Løsningen.Et sikkerhedsdomæne er et IT-netværk afgrænset af firewalls ud mod andre netværk, specielt Internettet, men indeholdende demilitariserede zoner. Inden for sikkerhedsdomænet kan dette være opdelt i forskellige zoner. I én zone er der gensidig tillid mellem alle applikationer, it-services og komponenter, således at er en aktør autentificeret til at have adgang til zonen, er denne aktør autentificeret til alle applikationer, IT-services og komponenter, som ligger inden for denne zone. Denne tillid udvides specificeret og kontrolleret af sikkerhedspolitikker med hensyn til tillidens omfang til andre zoner i sikkerhedsdomænet.Løsningen vil indeholde sager og dokumenter, der skal holdes fortrolige for en del af medarbejderne, f.eks. hemmelige patentsager. Derfor skal løsningen også være beskyttet mod fjendtlige angreb, der kan finde sted fra de netsegmenter, hvor interne brugerfladeapplikationer eller IT-services tilgår Løsningen.

Sikkerhed og brugerstyring

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.499 K Autentifikation af personaktører indenfor sikkerhedsdomænet

Det er et krav, at Løsningen skal foretage autentifikation af personaktører indenfor et sikkerhedsdomæne på følgende måder:• baseret på Microsoft Active Directory (AD)• baseret på attributter, der kan være specielle for en Løsning og som vedligeholdes i løsningen

404** 642

Side 179 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.500 K Brugeroplysninger om brugeres digitale identitet

Det er et krav, at oplysninger/kerneattributter om Løsningens lokale brugeres digitale identitet kan registreres i en kombination af Løsningen og directories eksterne til Løsningen. Grunddata, der findes i kundens Active Directory (AD) skal kunne anvendes som grunddata for Løsningen, herunder Løsnings-specifikke attributter, der kan vedligeholdes af en lokal administrator.

405** 694

3.501 K Grunddataskemaet skal kunne ændres

Det skal være muligt at udvide grunddataskema, hvis der sker ændringer i Active Directory master grunddataskema.

406** 695

3.502 K Løsnings-specifikke brugerattributter skal kunne udleveres

Det skal være muligt for Løsningen at udlevere Løsningsspecifikke brugerattributter til andre it-services eller applikationer

407 408

3.503 K Tildeling af autorisation af personaktører indenfor sikkerhedsdomænet

Det er et krav, at rettigheder i Løsningen kan tildeles og differentieres på baggrund af brugerens rolle og tilhørsforhold i organisationen. En bruger kan have flere roller og tilhørsforhold. Der opereres med følgende brugergrupper:• Brugere• Systemadministratorer• Øvrige

408* 409

Side 180 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.504 K Underbrugergrupper for Brugere

Det er et krav, at det er muligt for systemadministratorer at tildele og differentiere rettigheder for underbrugerroller til Brugere, f.eks. Sagsbehandler, Postfordeler, Journalmedarbejder, Revisor, Leder.

409** 645

3.505 K Underbrugergrupper for systemadministratorer. Det er et krav, at det er muligt for systemadministratorer at tildele og differentiere rettigheder for underbrugerroller, herunder:• Lokal administrator(kan f.eks. foretage mindre ændringer i brugerens egen brugergrænseflade og sætte regler op for sagsfordeling i enheden)• Administrativ administrator (kan f.eks. tildele subset af rettigheder)• Teknisk administrator (kan f.eks. udvikle på og konfigurere systemet)

410** 836

3.506 K Grupper for systemaktører.

Det er et krav, at det er muligt for systemadministratorer at tildele og differentiere rettigheder for følgende brugerroller:

Anden it-service Anden systemløsning

411** 412

3.507 K Tildeling af autorisation af aktører udenfor sikkerhedsdomænet

Det er et krav, at systemadministratorer for øvrige brugere skal kunne tildele og differentiere rettigheder for følgende brugergrupper:• Borger (portalbruger)• Virksomhed (portalbruger)• Anden systemløsning

412** 413

Side 181 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.508 K Beskrivelse af håndtering af autentifikation og autorisation

Leverandøren skal beskrive, hvorledes Løsningen opfylder behov beskrevet i krav 3.499 - 3.507. Specielt ønskes specificeret hvilke oplysninger/ attributter, der synkroniseres med LDAP, og hvilke der alene vedligeholdes i Løsningen.

Info. 77*

789

3.509 K Overholdelse af RBAC-standarden

Det et krav, at Løsningen anvender en rollebaseret adgangskontrol baseret på RBAC-kernen i RBAC-standarden.

414* 808

3.510 K Kryptering og signering

Det er et krav, at Løsningen i sin eksterne kommunikation understøtter Kundens anvendte og centrale SEPO-løsning til kryptering og signering af sikker kommunikation.

415** 696

3.511 K Uafviselighed

Det er et krav, at Løsningen i sin eksterne kommunikation har den valgmulighed, at kunne dokumentere uafviselighed af, at den eksterne part har afleveret en information eller at Løsningen har afsendt en information. Implementeringen skal baseres på: Enten logning og auditeret change management af komponenterne, der styrer kommunikationen Eller OCES certifikater og et signeringsbevis efter eDag2 specifikationen af et signeringsbevis.

416 417

Side 182 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.512 MK Klassificering af sager og dokumenter

Det er et krav, at Løsningen kan klassificere sager og dokumenter, således at der kan tildeles rettigheder for adgang og aktioner på sager og dokumenter efter minimum følgende model:

• ingen adgang: Brugeren kan ikke se sagen/dokumentet i registreringssystematikken, ej heller metadata.

• adgang til metadata: Brugeren kan se sagen/dokumentet i registrerings-systematikken.

• læseadgang: Brugeren har adgang til at læse sagen/dokumentet, men ikke tilføje i det (og dermed lave nye versioner).

• redigeringsadgang: Brugeren har ret til at tilføje i sagen/dokumentet (og dermed lave nye versioner), men ikke slette det.

• fuld adgang: Brugeren har ret til det hele inkl. at sætte sikkerhedsniveauet for det pågældende dokument (typisk niveau for egen producerede dokumenter).

417 418

3.513 K Beskrivelse af håndtering af klassificering


Info. 78*

790

Side 183 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.514 K Etablering af "auto-sluk" funktion

Det er et krav, at Løsningen understøtter en "auto-sluk" funktion (Session time-out), som sikrer, at der ikke er adgang til systemet uden anvendelse af password, såfremt systemet ikke anvendes inden for et parametersat tidsrum. Denne sikring kan ske ifht. Løsningen eller ifht. brugerens lokale sikkerhedsdomæne.

426 427

3.515 K Log

Det er et krav, at der i Løsningen som minimum forefindes:• En opfølgningslog• En administrator- og operatørlog• En fejllog

427 428

3.516 K Forslag til opfølgningslog

Det er et krav, at Leverandøren kommer med forslag til, hvordan opfølgningsloggen kan sammensættes og hvordan denne på en sikker måde kan tilgås af systemadministrator. Typiske aktiviteter inkluderer:• Logning, til brug for overvågning af datatilgang, funktionsadskillelse, svartidsbidrag, fejlhåndtering• Proaktiv monitorering,• Udtræk af kontrolrapporterLeverandøren skal i sit forslag besvare alle uddybende spørgsmål omkring opfølgningslogning i IT& Telestyrelsens ”Sikkerhedsvejledning i henhold til DS484 Version 1.0”. Det bemærkes, at Kunden i dag anvender ISO ISO27001.

428** 652

Side 184 af 198


Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.517 K Forslag til fejllog

Det er et krav, at Leverandøren kommer med forslag til, hvordan fejlloggen kan sammensættes og hvordan denne på en sikker måde kan tilgås af systemadministrator. Typiske aktiviteter inkluderer:• logning, til brug for fejlhåndtering• proaktiv monitoreringLeverandøren skal i sit forslag besvare alle uddybende spørgsmål omkring fejllog i IT & Telestyrelsens ”Sikkerhedsvejledning i henhold til DS484 Version 1.0”. Det bemærkes, at Kunden i dag anvender ISO ISO27001.

429** 653

8.8 Brugbarhed og tilgængelighedFor at sikre mulighed for brugerdialog skal relevant forretningslogik og relaterede services kunne stilles til rådighed via forskellige brugergrænseflader. Disses skærmbilleder skal udformes efter fælles skabeloner, som sikrer sammenhæng, genbrug, genkendelighed og være rettet mod såvel de forskellige typer af personaktører, som de terminaltyper, som de forskellige personaktører anvender.Behov for brugerfladefaciliteter er forskellige alt efter medarbejderens opgaver. Derfor er det vigtigt, at Løsningen kan facilitere flere brugerflader rettet mod hver opgavetype. Den enkelte medarbejder skal have adgang til netop de informationer og handlinger, som er relevante for dem og ikke andre. Ligeledes er det vigtigt, at Leverandøren lader sig inspirere af nye fremskridt inden for klienter, som har til formål at minimere antallet af klik og sideopdateringer. Tilsvarende skal dekobling af forretningsservices og brugerflade sikre, at brugerfladen kan varieres, således at udvalgte arbejdsgange kan tilgås af f.eks. en PDA eller en tyk klient, foruden via en browser. Det er vigtigt for adoptionen af Løsningen, at der er lagt stor vægt på brugervenlighed, og dette er nærmere specificeret i afsnit 7.2.1. I nærværende afsnit suppleres med en række teknisk og standard orienterede krav til præsentationslaget. Begge dele vil blive testet indgående i brugervenlighedstesten.

Side 185 af 198

Brugbarhed og tilgængelighed

Krav

Kravtype


PVS ID

3.518 MK Funktionel tilgængelighed

Det er et krav, at Løsningen skal opfylde WCAG 2.0 tilgængelighedskravene på niveau AA . Løsningen vil således også skulle opfylde dette sæt krav.

WCAG 2.0 kan findes her: http://www.itst.dk/it-arkitektur-og-standarder/tilgengelighed/verktojskassen/wcag-2.0/wcag-vejledning#vejledningsniveauer-i-wcag-2

438** 580

3.519 K Beskrivelse af test af funktionel tilgængelighed

Leverandøren skal redegøre for, hvorledes en test af funktionel tilgængelighed vil blive foretaget.

Info. 85*

792

Side 186 af 198

http://www.itst.dk/it-arkitektur-og-standarder/tilgengelighed/verktojskassen/wcag-2.0/wcag-vejledning#vejledningsniveauer-i-wcag-2




Krav

Kravtype


PVS ID

3.520 K Tilgængelighed gennem forskellige brugergrænseflader

Det er et krav, at brugerfladen for Løsningens forskellige funktionsområder kan variere afhængigt af opgavens karakter. Fx skal ressourcekrævende og ofte udførte opgaver internt hos Kunden kunne udføres i en brugergrænseflade, hvor der er fokuseret på svartider og usability. Tilsvarende kan andre scenarier tale for en brugerflade, der sikrer optimal tilgængelighed og teknologiuafhængighed udefra. Specielt skal det være muligt i specifikke arbejdsgange at anvende en PDAs eller en smartphones brugerflade

439* 682

3.521 K Specificering af mulige brugergrænseflader

Leverandøren skal specificere, hvilke typer af brugerflader og brugerfladeterminaler (som PDAs og smartphones) Løsningen understøtter.

Info. 86*

793

3.522 K Layout mv. i webgrænseflade

Det er et krav, at Løsningens skærmbilleder baseres på XHTML 1.0 eller nyere. Skærmbilledernes layout skal implementeres med CSS 2.0, og skal kunne gennemgå W3C HTML/XHTML og CSS 2.0 validering.

440 441

3.523 MK Præsentation af funktionalitet i browser

Det er et krav, at Løsningens skærmbilleder som minimum er optimeret til visning med MS Internet Explorer 8.0 og 9.0. Alle skærmbilleder skal kunne skjules, minimeres og lukkes. Der skal kunne tages skærmdumps af alle skærmbilleder ved hjælp af PrintScrn-knappen.

441** 651

Side 187 af 198


Krav

Kravtype


PVS ID

3.524 O Præsentation af funktionalitet i browser 2

Løsningens skærmbilleder skal være optimeret til visning med de nyeste versioner af Safari, Mozilla Firefox, samt Google Chrome.

- 655

3.525 K Redegørelse - Præsentation af funktionalitet via webparts

Leverandøren bedes redgøre for, hvilke dele af systemets grænseflade, der kan præsenteres via Sharepoint webparts.

- 809

3.526 K Navngivning – i brugergrænsefladen, mv.

Det er et krav, at navngivningen i brugergrænsefladen, i rapporter og ved udvekslinger skal kunne afspejle de forretningsbegreber Kunden anvender.

443* 685

8.9 Åbenhed og dokumentationÅbenhed og dokumentation

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.527 K Håndtering af obligatoriske åbne dokumentstandarder

Det er et krav, at Løsningen kan håndtere:• alle de åbne obligatoriske standarder i det omfang det er relevant, fx skal dokumenttjenesten kunne håndtere ODF og OOXML som formater• de tekniske standarder, der er anbefalet i OIO-kataloget, fx skal Løsningen kunne anvende NemID

444** 654

Side 188 af 198

Åbenhed og dokumentation

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.528 K Anvendelse af standarder udgivet på Digitalisér.dk

Det er et krav, at anvendelse af standarder følger anbefalingerne i Digatalisér.dk. Løsningen skal anvende den stærkest anbefalede it-standard indenfor de relevante kategorier. Leverandøren skal endvidere redegøre for og argumentere for afvigelser fra øvrige standarder i Digitalisér.dk.

445 446

3.529 K Beskrivelse af afvigelser fra Digitaliser.dk


Info. 87*

794

3.530 MK Dokumenterede service-interfaces

Det er et krav, at Løsningen tilbyder åbne dokumenterede snitflader, der som minimum understøtter webservices. Dette gælder også for funktionalitet, der ikke er omfattet af standardisering, som kan anvendes til at udvide funktionaliteten.

446** 447

3.531 K Dokumenterede applikationer, it-services og komponenter

Det er et krav, at Løsningen på generelt niveau gennem et applikations-landkort beskriver den logiske struktur af Løsningen, og den interne kommunikation mellem de logiske enheder illustreret.

447 448

3.532 K Dokumenteret personaktørkontekst

Det er et krav, at Løsningen på generelt niveau gennem en kontekstfigur beskriver de personaktører, der anvender Løsningen.

448 449

Side 189 af 198

Åbenhed og dokumentation

Krav

Kravtype

Krav Reference

FESD2 ref.

PVS ID

3.533 MK Dokumenteret integrationskontekst

Det er et krav, at Løsningen på generelt niveau gennem en kontekstfigur beskriver de systemaktører, der integrerer med Løsningen.

449 450

3.534 MK Dokumentation af datamodeller

Det er et krav, at Løsningens logiske datamodel skal dokumenteres med et UML-klassediagram eller et ER-diagram. Derudover ønskes en overordnet beskrivelse af de fagspecifikke tabeller samt tekstbeskrivelser af felter (attributter) med følgende oplysninger:

• Sigende navn

• Definition/meningsfyldt betydning

• Syntaks, der skal kunne genkendes af en databaseadministrator

• Kilde (relation til en person- eller systemaktør, internt modul/funktion eller en usecase).

450 451

Side 190 af 198

9. Løsningsbeskrivelse

[Her anfører Leverandøren besvarelser, redegørelser m.m. for en række krav jf. nedenfor. Løsningsbeskrivelsen skal referere til krav ID. ]Leverandøren skal her redegøre for, hvorledes nedenfor angivne specifikke krav fremsat af Kunden i nærværende bilag påtænkes opfyldt. Leverandøren opfordres til at besvare kravene fyldestgørende og supplere med eksempler, skærmbilleder o.l., så det bliver nemmere for Kunden at forholde sig til, hvordan den tilbudte løsning rent praktisk understøtter Kundens behov. For forklaring af, hvordan besvarelserne i dette kapitel indgår i Kundens tilbudsevaluering, henvises der til dokumentet ”Udbudsbetingelser”.

9.1 Lovgivning og standarderHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.73.10 […Leverandørens besvarelse…]

9.2 Forretningsobjekter Løsningen skal understøtte

9.2.1 ArkivHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.25[…Leverandørens besvarelse…]

9.2.2 SagHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.283.333.363.42[…Leverandørens besvarelse…]

Side 191 af 198

9.2.3 Dokument - forretningsobjektHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.63[…Leverandørens besvarelse…]

9.2.4 Interessent – forretningsobjekt Her indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.963.99[…Leverandørens besvarelse…]

9.2.5 Opgaveklassifikation - forretningsobjektHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.1043.1063.112[…Leverandørens besvarelse…]

9.3 Arbejdsopgaver Løsningen skal understøtte

9.3.1 Delarbejdsgange9.3.1.1 Opretter sag – delarbejdsgangHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.125[…Leverandørens besvarelse…]

9.3.1.2 Afslutter sag – delarbejdsgangHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.144[…Leverandørens besvarelse…]

Side 192 af 198

9.3.1.3 Tilknytter Interessent – delarbejdsgang Her indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.1463.155[…Leverandørens besvarelse…]

9.3.1.4 Modtager og placerer post – delarbejdsgangHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.1573.1593.1693.1733.179[…Leverandørens besvarelse…]

9.3.1.5 Danner og afsender post – delarbejdsgangHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.1813.1843.1953.201[…Leverandørens besvarelse…]

9.3.1.6 Opretter og behandler dokument - delarbejdsgangHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.2033.206[…Leverandørens besvarelse…]

9.3.1.7 Udveksler sager og dokumenter - delarbejdsgangHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:

Side 193 af 198

3.2083.210[…Leverandørens besvarelse…]

9.3.1.8 Afleverer til offentligt arkiv – delarbejdsgang Her indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.2123.222[…Leverandørens besvarelse…]

9.3.1.9 Danner sagsprocesoverblik – delarbejdsgang Her indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.231[…Leverandørens besvarelse…]

9.3.1.10 Hent information til sagsbehandling – delarbejdsgangHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.2333.237[…Leverandørens besvarelse…]

9.3.1.11 Ekstern høring – delarbejdsgang Her indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.243[…Leverandørens besvarelse…]

9.3.1.12 Behandler aktindsigt – delarbejdsgang Her indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.245 […Leverandørens besvarelse…]

9.3.2 Centrale behovstemaer og funktionaliteter

Side 194 af 198

9.3.2.1 Brugervenlighed Her indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.2483.2533.2553.2603.264 […Leverandørens besvarelse…]

9.3.2.2 AutomatiseringHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.269 […Leverandørens besvarelse…]

9.3.2.3 Søgning og fremfindingHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.288 […Leverandørens besvarelse…]

9.3.2.4 Samlemapper Her indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.297[…Leverandørens besvarelse…]

9.3.2.5 SystemadministrationHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.3043.3153.319 […Leverandørens besvarelse…]

Side 195 af 198

9.3.2.6 Workflow funktionalitetHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.329 […Leverandørens besvarelse…]

9.3.3 Øvrige behovstemaer og funktionaliteter9.3.3.1 Scanning og OCRHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.3513.353[…Leverandørens besvarelse…]

9.3.3.2 Dagsorden og udvalgsbehandlingHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.3553.357[…Leverandørens besvarelse…]

9.3.3.3 ForelæggelseHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.360 […Leverandørens besvarelse…]

9.3.3.4 Visning og overblikHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.4133.4293.432[…Leverandørens besvarelse…]

Side 196 af 198

9.4 Ikke-funktionelle krav

9.4.1 Arkitektur og miljøerHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.4373.438[…Leverandørens besvarelse…]

9.4.2 DatamodelHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.4403.442 […Leverandørens besvarelse…]

9.4.3 Struktur, forandringsparathed og platformHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.4543.4583.4623.464 […Leverandørens besvarelse…]

9.5 Integration

9.5.1 Integration genereltHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.467 […Leverandørens besvarelse…]

9.5.2 Eksport til CRMHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.483

Side 197 af 198

[…Leverandørens besvarelse…]

9.5.3 Integration til økonomisystemHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.486 […Leverandørens besvarelse…]

9.5.4 Integration – integrationsmønstre, kommunikationsstandarder, integritet, sikkerhed og pålidelighedHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.494 […Leverandørens besvarelse…]

9.6 Sikkerhed og brugerstyringHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.5083.513[…Leverandørens besvarelse…]

9.7 Brugbarhed og tilgængelighedHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.5193.5213.525 […Leverandørens besvarelse…]

9.8 Åbenhed og dokumentationHer indsætter Leverandøren løsningsbeskrivelse for følgende krav:3.529[…Leverandørens besvarelse…]

Side 198 af 198

03... · Web viewVersion gemt efter Word gik ned. XMHK. 0.9. 06.07.2012. Kaj J. kommentarer...

Documents

Transcript of 03... · Web viewVersion gemt efter Word gik ned. XMHK. 0.9. 06.07.2012. Kaj J. kommentarer...