Bilag 07b Modernisering Lex Dania klient
Bilag 07b
Modernisering Lex Dania klient
Kontrakt om drift, vedligehold og videreudvikling af Xxx Xxxxx produktion og Statstidende, herunder Modernisering af Xxx Xxxxx klient
Vejledning til tilbudsgiver:
Dette afsnit er en vejledning til tilbudsgiver i forhold til, hvordan dokumentet skal læses og forstås, og hvad der skal udfyldes og hvordan af tilbudsgiveren.
Instruktionen angivet med kursiv i […] er vejledning til tilbudsgiver i forhold til tilbudsgivers besvarelse og slettes inden Kontraktens underskrivelse. Tilbudsgiver skal såfremt det er angivet som en del af instruktionen, udarbejde en besvarelse af bilaget i forbindelse med udarbejdelse af sit tilbud. Tilbudsgiver kan indsætte sin besvarelse i kravboksene ved at overskrive instruktionsteksten, eller - hvis dette er angivet som mulighed i instruktionen – kan tilbudsgiver vedlægge sin besvarelse som underbilag og indsætte henvisning til sådanne underbilag i kravboksen ved at overskrive instruktionsteksten.
Tilbudsgiver gøres desuden opmærksom på, at bilaget kan indeholde mindstekrav, som tilbudsgiver skal opfylde for at komme i betragtning til den udbudte opgave. Ikke-opfyldelse af mindstekrav medfører, at tilbuddet som helhed er ukonditionsmæssigt.
Denne vejledning slettes inden kontraktunderskrift.
1Indholdsfortegnelse
2.1 Kravspecifikations opbygning 6
2.2 Bilagsspecifikke definitioner 6
3 Kontekst, aktører og brugerrejser 9
3.2.1 Informationsleverandørerne 10
3.3.1 Proces A (Simpel): Proces for produktion og publicering af vejledning 12
3.3.2 Proces B (Mellem): Proces for produktion og publicering af bekendtgørelse 13
4.1 Læsevejledning til funktionelle krav 21
4.1.4 Snitfladebeskrivelser 22
4.2 Brugerprofiler i den moderniserede Lex Dania klient 22
4.3 Dokumenttyper og dokumentstatus 24
4.3.2 Lov- og beslutningsforslag 25
4.4 Tema 1 – Brugeradministration 25
4.4.1 Processer for brugeradministration 25
Epic 01 – Administration af brugere (CST Superbruger) 25
Epic 02 – Administration af brugere (Decentralt på ressortniveau) 26
4.5 Tema 2 – Administration 26
4.5.1 Processer for Administration 26
Epic 03 – Vedligeholdelse af lister 27
Epic 04 – Ajourføring af metadata 27
Epic 05 – Ekstraordinær ajourføring af dokumenter 27
Epic 09 – Notifikationer og driftsmeddelelser 29
4.6 Tema 3 – Indlæsning og eksportering 30
4.6.1 Processer for indlæsning og eksportering 30
Epic 11 – Førstegangsindlæsning 30
Epic 12 – Eksportering til redigering 31
Epic 13 – Indlæsning af redigeret dokument 31
Epic 14 – Eksportering af kopi 32
Epic 15 – Indlæsning af andre filtyper end ldex 32
4.7 Tema 4 – Dokumentsøgning 32
4.7.1 Processer ved dokumentsøgning 32
Epic 16 – Simpel dokumentsøgning 33
Epic 17 – Avanceret dokumentsøgning 33
Epic 18 – Visning af seneste fremsøgte dokumenter 33
Epic 19 – Gem søgekriterier 34
4.8 Tema 5 – Dokumentbearbejdning 34
4.8.1 Processer for dokumentbearbejdning 34
Epic 20 – Visning af dokumentoplysninger 35
Epic 21 – Indrapportering af stamdata 35
Epic 22 – Indrapportering af redaktionelle oplysninger 35
Epic 23 – Indrapportering af referencer 36
Epic 27 – Optagelsesanmodning 37
4.9 Tema 6 – Lovtidende redaktion og kundgørelse 38
4.9.1 Processer for Lovtidende redaktion og kundgørelse 38
Epic 28 – Nedskrivning af dokument 39
Epic 29 – Redaktionel bearbejdning 39
Epic 30 – Påføring af emneord 39
Epic 31 – Overførsel af dokument 40
Epic 32 – Simulering af konsekvensberegningen 40
Epic 33 – Bestilling af kundgørelse 40
Epic 34 – Omtryk af dokument 41
4.10 Tema 7 – Sporbarhed og versionering 41
4.10.1 Processer for sporbarhed og versionering 41
Epic 35 – Visning af dokumentstatus og logs 42
Epic 36 – Visning af tidligere dokumentversioner 42
Epic 37 – Versionsstyring af dokumenter 42
Epic 38 – Kvitteringer ved bestemte handlinger 43
Epic 39 – Overblik over tidligere bestilte kundgørelser 43
4.11.1 Processer i Folketinget 44
Epic 41 – Nedskrivning af dokument (FT) 45
Epic 42 – Behandling af styredokumenter 45
Epic 43 – Navigering i sagsforløb 45
Epic 44 – Transformering af dokumenter 46
Epic 45 – Omtryk af dokument (FT) 46
Epic 46 – Skift folketingssamling 47
Epic 47 – Vedligeholdelse af lister (FOB) 47
4.12 Tema 9 – Offentlighedsportalen 47
4.12.1 Processer for OPO-dokumenter 48
Epic 49 – Dokumentreferencer 48
Epic 50 – Vedligeholdelse af OPO-lister 48
4.13 Tema 10 – Brugerhjælp og personlig konfiguration 49
4.13.1 Processer for brugerhjælp og personlig konfiguration 49
Epic 51 – Personlige konfigurationer 49
Epic 52 – Visning af e-læringsmodul 50
5.1.2 Komponenter og Snitflader 53
5.2 Krav til realisering af målarkitekturen 56
5.2.1 Standardprogrammel og Kundespecifikt Programmel 56
5.3 Implementering af Løsningen 57
2Indledning
Dette dokument indeholder krav til udviklingen af den moderniserede Lex Dania klient. Dokumentet er udformet som en kravspecifikation med henblik på tilbudsevaluering og har desuden til hensigt at fungere som grundlaget for udviklingsprojektet.
Kravspecifikationen er udover at være et juridisk dokument, der indgår som bilag til Kontrakten, således også at betragte som et analysedokument, der afdækker behov og krav til den moderniserede Lex Dania klient på et overordnet niveau. I praksis indeholder kravspecifikationen første bud på den ”product backlog”, som projektet etablerer ved opstart af udviklingen. Kravene vil derefter som led i den Agile Udviklingsmetode, jf. Bilag 10b (Udviklingsmetode), skulle yderligere nedbrydes, modnes og præciseres.
2.1Kravspecifikations opbygning
Kravspecifikationen er opbygget i afsnit, som indeholder krav til den moderniserede Lex Dania klient samt baggrundsbeskrivelser efter følgende opbygning:
Afsnit 1: Indeholder en introduktion til nærværende bilag.
Afsnit 2: Beskriver den kontekst, som den moderniserede Lex Dania klient skal befinde sig i, herunder en beskrivelse af de aktører, som skal interagere med den moderniserede Lex Dania klient.
Afsnit 3: Indeholder de funktionelle krav til den moderniserede Lex Dania klient, beskrevet med fokus på Kundens forretningsmæssige behov. Kapitlet indledes med en læsevejledning til forståelse af metoden, der er anvendt til afdækning af de funktionelle krav, samt et overblik over de definerede temaer, som de funktionelle krav er opdelt i. De funktionelle krav er herefter beskrevet og opdelt i temaer med en eller flere Epics til hvert tema.
Afsnit 4: Indeholder de ikke-funktionelle krav til den moderniserede Lex Dania klient, herunder bl.a. krav til målarkitektur, integrationer, sikkerhed, samt krav til brugervenlighed.
2.2Bilagsspecifikke definitioner
Ved Civilstyrelsen (CST) forstås den statslige styrelse som særskilt aktør, der har ansvaret for bl.a. daglig kundgørelse af Lovtidende via særlige optagelses- og publiceringslister, administration af Systemet og Løsningen, samt support til Informationsleverandører. Civilstyrelsen er således ikke blot Kunden i relation til Kontrakten om end der er juridisk sammenfald på kontraktindgåelsestidspunktet.
Ved Leverancen forstås i dette bilag alle de ydelser, som Leverandøren skal levere i forbindelse med udviklingsopgaven Modernisering af Lex Dania klient.
Ved Løsningen forstås i dette bilag produktet af udviklingsopgaven Modernisering af Lex Dania klient. Løsningen omfatter dels udviklingen af ny brugergrænseflade, dels integrering med øvrige snitflader i Lex Dania produktion.
Ved Metadata forstås i dette bilag alle oplysninger og data, herunder Stamdata, tilknyttet et dokument i Løsningen, og som ikke er redaktionelle oplysninger. Metadata kan være medfødt fra det indlæste dokument eller indrapporteret via Løsningen.
Ved Målarkitektur forstås i dette bilag den ønskede udvikling og etablering af den moderniserede klient inden for et system, idet den tager udgangspunkt i Kundens forretningsmæssige krav og beskriver arkitekturvisionen for hele systemet med fokus på leverancens mål, "Modernisering af Xxx Xxxxx klient".
Ved Stamdata forstås i dette bilag alle oplysninger og data, der indrapporteres via Løsningen.
Ved Folketinget forstås i dette Informationsleverandøren Folketinget som aktør i Løsningen. Se hertil afsnit 3.2.1.
Ved Folketinget (som parlament) forstås i dette bilag Folketinget når det, eller dets medlemmer, arbejder som parlament som del af lovgivningsprocessen der understøttes af Løsningen og Systemet men ikke som aktør.
2.3Baggrund og formål
Xxx Xxxxx produktion er det regelproduktionssystem, der danner grundlaget for produktion og publicering af retsforskrifter og andre normerende dokumenter på xxxxxxxxxx.xx og xxxxxxxxxxxxxxx.xx. Produktionssystemet består af Windows applikationerne Xxx Xxxxx editor Xxxxxxx og Xxx Xxxxx klient. Xxx Xxxxx produktion og sammenhængene mellem applikationerne er nærmere beskrevet i Bilag 03 (Beskrivelse af Kundens nuværende system – Xxx Xxxxx produktion og Statstidende).
Lex Dania klient, som er det centrale styringsværktøj i produktionssystemet blev idriftsat den 1. januar 2008 i version 1.0. Lex Dania klient kan beskrives som et avanceret specialudviklet content management system (CMS), der kun understøtter dokumenter skrevet i LDe Eunomia. Systemet blev udviklet på baggrund af de hidtidige erfaringer fra det tidligere system, gennem analyse af de lovtekniske og statsretlige regler, samt ved tæt dialog med Brugerne af systemet herunder særligt Folketinget og ministerier. Klienten er sidenhen blevet vedligeholdt og videreudviklet løbende. Den nuværende version af Xxx Xxxxx klient har versions-nummer 5.7.0. Se Bilag 03a (Teknisk beskrivelse af Lex Dania klient) for en nærmere teknisk beskrivelse af eksisterende Lex Dania klient.
Kunden vurderer den nuværende forretningsunderstøttelse i backend og frontend som værende tilfredsstillende, både for så vidt angår Civilstyrelsens egne forretningsbehov samt Brugernes forretningsbehov.
Kunden har imidlertid indenfor de seneste par år gennemgået en række opgraderinger på visse systemkomponenter i Lex Dania produktion. Kunden har i den sammenhæng vurderet, at en modernisering af Xxx Xxxxx klient er det næste skridt i vedligeholdelsen af produktionssystemet med henblik på vedvarende at sikre autenticitet, fortrolighed, tilgængelighed, og imødekommelse af fremtidige forretningsbehov samt optimering af performance.
Formålet med moderniserende af Lex Dania klient er således at udvikle en ny og tidssvarende løsning til understøttelse af nuværende og fremtidige forretningsbehov.
2.4Leverancens omfang
Leverancens omfatter udviklingen af den moderniserede Lex Dania klient efter den Agile Metode beskrevet i Bilag 10b (Udviklingsmetode).
Foruden udvikling af programmel til opfyldelse af Kundens funktionelle og ikke-funktionelle krav, omfatter Leverancen således styring og gennemførelse af alle ydelser tilknyttet udviklingsopgaven, herunder nedbrydning af krav i mindre dele, planlægning af sprints, afholdelse af workshops m.v. – alt sammen i tæt samarbejde med Xxxxxx.
Det forventes, at moderniseringen af Xxx Xxxxx klient vil berøre de integrationer og snitflader, Lex Dania klient benytter i produktionssystemet, såsom Lex Dania serveren. En mere teknisk beskrivelse af Lex Dania klient og dets snitflader kan findes i Bilag 03a (Teknisk beskrivelse af Lex Dania klient) med tilhørende dokumentation.
I det omfang udviklingsfasen afdækker behov for ydelser i form af ny funktionalitet eller ændringer i relation til øvrige snitflader, som umiddelbart ikke er indeholdt i Kundens krav i nærværende bilag, skal Leverandøren også levere disse ydelser til opfyldelse af Løsningens samlede forretningsunderstøttelse som en del af Løsningen.
3Kontekst, aktører og brugerrejser
Den moderniserede Lex Dania klient skal erstatte den nuværende Lex Dania klient, som er en delkomponent i Xxx Xxxxx produktion. For at indramme, hvad Leverancen indebærer, beskriver dette afsnit i helt korte træk den kontekst, hvori den nuværende Lex Dania klient indgår. Samtidig gives der eksempler på de typiske forretningsprocesser, som systemet understøtter.
3.1Kontekst
Xxx Xxxxx produktion understøtter den daglige produktion af love og regler, der udstedes af centrale statslige myndigheder. Informationsleverandørerne er således Folketinget, Folketingets Ombudsmand og samtlige ministerier.
I de fleste tilfælde starter en Informationsleverandør, dvs. en professionel Xxxxxx, med at skrive et dokument i LDe Eunomia, hvorefter dokumentet bliver indlæst i Lex Dania klient. Her beriges dokumentet med metadata og alt efter dokumenttypen kan dokumentet bevæge sig imellem Ministerium, Folketinget og Civilstyrelsen.
Når et dokument er færdigbearbejdet, publiceres det i slutbrugersystemet, som består af en række hjemmesider.
Nedenfor er den overordnede kontekst for Xxx Xxxxx klient illustreret:
Figur 1 - Simpel illustration af Xxx Xxxxx klients placering i produktionssystemet
3.2Aktører
I dette afsnit beskrives kort de enkelte aktører i kontekst af Lex Dania klient. Aktørerne vil være de samme og have samme roller i den moderniserede Xxx Xxxxx klient.
3.2.1Informationsleverandørerne
Ministerierne
Ansvaret for udarbejdelse af love og regler ligger som udgangspunkt hos regeringen. Det er derfor ministerierne med underlæggende styrelser og myndigheder, udarbejder størstedelen af de dokumenter, der produceres i Xxx Xxxxx produktion. Dokumenterne skrives i LDe Xxxxxxx og indlæses efterfølgende i Lex Dania klient til videre bearbejdning og publicering. Fra Lex Dania klient frigives dokumenterne enten direkte til slutbrugersystemet, til Folketingets eller til Civilstyrelsens videre behandling. Dokumentflowet afhænger af dokumenttypen.
Folketinget
Folketingets rolle er at viderebearbejde de lovforslag, der produceres og fremsættes af ministerierne under regeringen. Folketinget opretter og behandler dog private lovforslag uden regeringens mellemkomst. Derudover producerer Folketinget en række særlige dokumenttyper, som alene anvendes i folketingsprocessen. Folketinget benytter derfor Lex Dania klient i forbindelse med stort set alle formelle dokumentgange i folketingsprocessen. Som følge af Folketingets særlige rolle i produktionssystemet deltager Folketinget i den løbende udvikling for så vidt angår processer og dokumenthåndtering i Lex Dania klient.
Folketingets Ombudsmand
Folketingets Ombudsmand har adgang til at udarbejde og publicere et mindre antal særegne dokumenttyper, herunder Udtalelser (FOB) og Inspektionssager. Derudover vedligeholder ombudsmanden sine egen myndigheds- og emneordsregistre.
3.2.2Civilstyrelsen
Civilstyrelsen anvender Xxx Xxxxx klient i den daglige kundgørelse af Lovtidende via særlige optagelses- og publiceringslister. Civilstyrelsen foretager derved det sidste lovtekniske kvalitetstjek inden love og regler offentliggøres.
Civilstyrelsen fungerer som superbrugere med ansvar for den overordnede brugerstyring og adgang til alle administrationsmoduler i systemet.
Derudover yder Civilstyrelsen support til informationsleverandørerne og afholder kursus i bl.a. brugen af Lex Dania klient og regeludstedelsesprocessen i al almindelighed.
Civilstyrelsen har også ansvaret for drift og udvikling af Lex Dania klient, herunder for leverandørstyringen, planlægning af udviklingstiltag, afholdelse af beredskabsøvelser m.v.
3.2.3Slutbruger
En slutbruger er den offentlige Bruger, der tilgår hjemmesiderne i slutbrugersystemet, hvorpå dokumenter, der administreres i Lex Dania klient, offentliggøres. Det drejer sig om xxxxxxxxxx.xx, xxxxxxxxxxxxxxxxxx.xx, xxxxxxxxxxxxxxx.xx og xxxxxxxxxxxxxxxxxxxxx.xx. Alle kan tilgå disse hjemmesider uden krav om brug af log-in eller lignende. Slutbrugere har ikke adgang til Lex Dania klient.
3.2.4Serviceaftagere
Serviceaftagerne er professionelle dataaftagere, der benytter sig af de webservices Civilstyrelsen udstiller på det data, der lægges i slutbrugersystemet1. Serviceaftagere har ikke adgang til Lex Dania klient.
3.3Brugerrejser
Den moderniserede Lex Dania klient skal udvikles i kontekst af de forretningsprocesser, som produktionssystemet understøtter. Forretningsprocesserne er udtryk for de arbejdsgange, der sker hos Informationsleverandørerne i regelarbejdet.
I dette afsnit skitseres tre forskellige brugerrejser af forskellig kompleksitet, hvor den moderniserede Lex Dania klient, vil spille den helt centrale rolle på samme vis som i den nuværende løsning.
Der er ikke tale om en fuldstændig redegørelse for alle forretningsprocesser relateret til klientens rolle, idet andre dokumenttyper, end de udvalgte, kan have et anderledes procesforløb. Procesbeskrivelserne skal alene tjene som eksempler på typiske procesforløb, og skal give en forståelse for, hvordan de forskellige aktører har forskellige roller i processerne.
3.3.1Proces A (Simpel): Proces for produktion og publicering af vejledning
Ministeriernes udstedelse af vejledning er et eksempel på en meget simpel forretningsproces, hvor brugerrejsen alene omfatter én aktør og få processkridt.
Figur 2 - Proces for produktion og publicering af vejledning
ID |
Beskrivelse |
A.1 |
Udkast til vejledning Ministeriets udarbejdelse af vejledning starter typisk som et udkast i MSWord, der godkendes internt og evt. sendes i offentlig høring. |
A.2 |
Vejledning opmærkes i Eunomia Vejledningen opmærkes i Eunomia på baggrund af MSWord udgaven. Opmærkningen omfatter al indhold i forskriften, dvs. vejledningens tekst og eventuelle bilag. Dokumentet gemmes lokalt i specialformatet ldex. Principielt kan vejledningen skrives i Eunomia fra start, hvorved A.1. springes over. |
A.3 |
Vejledning indlæses i Lex Dania klient og påføres metadata m.v. Ldex-filen indlæses i Lex Dania klient. Dokumentet oprettes derved i databasen som et dokument med et unikt DocID. Dokumentets stamkort beriges med oplysninger om underskriftsdato, underskriver, journalnummer m.v. Ligeledes påføres eventuelle referencer til andre dokumenter i databasen. |
A.4 |
Evt. rettelser i Eunomia Skal dokumentindholdet tilrettes, eksporteres det til redigering fra Lex Dania klient, hvorefter dokumentet kan åbnes og bearbejdes i Xxxxxxx. Efterfølgende indlæses det i Lex Dania klient som et redigeret dokument på det dokumentkort, forskriften blev indlagt på oprindeligt. Derved beholder dokumentet det samme DocID i hele dets levetid, og det er muligt at følge dokumentets ændringshistorik under ”Status”. Et dokument kan eksporteres og genindlæses adskillige gange, inden det frigives. |
A.5 |
Vejledning frigives i Xxx Xxxxx klient Når ministeriet har verificeret at vejledningens indhold er korrekt, samt har påført alle relevante metadataoplysninger og referencer, frigives vejledningen, hvorefter den lægges klar til brugersystem. |
A.6 |
Vejledning offentliggøres på xxxxxxxxxxxxxxx.xx I forbindelse med de faste jobkørsler over midnat, offentliggøres vejledningen på xxxxxxxxxxxxxxx.xx. |
Tabel 1 - Proces for produktion og publicering af vejledning
3.3.2Proces B (Mellem): Proces for produktion og publicering af bekendtgørelse
Ministeriernes udstedelse af bekendtgørelser er eksempel på en mellemkompliceret proces, som både involverer et ministerium og Civilstyrelsen.
Figur 3 - Proces for produktion og publicering af bekendtgørelse
ID |
Beskrivelse |
B.1 |
Udkast til bekendtgørelse udarbejdes og sendes i høring Ministeriets udarbejdelse af en bekendtgørelse starter typisk som et udkast i MSWord, der godkendes internt og sendes i offentlig høring til høringsberettigede. |
B.2 |
BEK opmærkes i Eunomia Bekendtgørelsen opmærkes i Xxxxxxx på baggrund af MSWord udgaven. Opmærkningen omfatter al indhold i forskriften, dvs. paragraffer (struktureret del) og eventuelle bilag (ustruktureret del). Dokumentet gemmes lokalt i specialformatet ldex. Principielt kan bekendtgørelsen skrives i Eunomia fra start, hvorved B.1. springes over. |
B.3 |
BEK indlæses i Lex Dania klient og påføres metadata m.v. Ldex-filen indlæses i Lex Dania klient. Dokumentet oprettes derved i databasen som et dokument med et unikt DocID. Dokumentets stamkort beriges med oplysninger om underskriftsdato, underskriver, journalnummer m.v. Ligeledes påføres eventuelle referencer til andre dokumenter i databasen. |
B.4 |
Evt. tilrettelser i Eunomia Skal dokumentindholdet tilrettes, eksporteres det til redigering fra Lex Dania klient, hvorefter dokumentet kan åbnes og bearbejdes i Xxxxxxx. Efterfølgende indlæses det i Lex Dania klient som et redigeret dokument på det dokumentkort, forskriften blev indlagt på oprindeligt. Derved beholder dokumentet det samme DocID i hele dets levetid, og det er muligt at følge dokumentets ændringshistorik under ”Status”. Et dokument kan eksporteres og genindlæses adskillige gange, inden det frigives, jf. B.5. |
B.5 |
Frigivelse og anmodning om optagelse i Lovtidende Når ministeriet har verificeret at bekendtgørelsens indhold er korrekt, samt har påført alle relevante metadataoplysninger og referencer, frigives og optagelsesanmodes bekendtgørelsen, hvorefter rettighederne overgår til Civilstyrelsen. |
B.6 |
Lovteknisk og redaktionel gennemgang Civilstyrelsen modtager og behandler optagelsesanmodede dokumenter via de særlige publieringslister i Xxx Xxxxx klient. Civilstyrelsen læser lovteknisk og redaktionel korrektur på bekendtgørelsen. Eventuelle spørgsmål eller bemærkninger drøftes med ressortministeriet – typisk telefonisk, men kan også foregå via mail. |
B.7 |
Er forskriften fejlfri? Hvis Civilstyrelsen ikke har noget at bemærke, dvs. at bekendtgørelsen betragtes som fejlfri, overfører Civilstyrelsen bekendtgørelsen til dagens kundgørelsesliste. Hvis Civilstyrelsen aftaler med ressortministeriet, at der skal ske tilretninger, nedskrives dokumentet, hvorefter rettighederne går tilbage til ministeriet. |
B.8 |
BEK nedskrives til ministeriet, som indarbejder rettelser Når Civilstyrelsen har nedskrevet dokumentet, foretager ressortministeriet de nødvendige rettelser på stamkortet og/eller i dokumentets indhold ved at eksportere til Eunomia, jf. B.4. Efter rettelserne er foretaget, frigives og optagelsesanmodes dokumentet på ny, jf. B.5 og B.6. |
B.9 |
Bekendtgørelsen kundgøres i Lovtidende Civilstyrelsen bestiller hver dag kundgørelse af de forskrifter, som styrelsen har godkendt og overført til kundgørelse. Forskrifter kan enten kundgøres ordinært eller ekstraordinært. Kundgørelsen sker ved en række jobs, der eksekveres kort efter midnat. Bekendtgørelsen kundgøres på xxxxxxxxxx.xx og offentliggøres samtidig på xxxxxxxxxxxxxxx.xx |
Tabel 2 - Proces for produktion og publicering af bekendtgørelse
3.3.3Proces C (Kompliceret): Proces for produktion, behandling og publicering af lovforslag som fremsat af regeringen
Lovforslagsprocessen er en længere og kompliceret proces, der fra lovforslagets fremsættelse til den endelige lovs kundgørelse i Lovtidende, involverer brugere hos et ministerium, Folketinget og Civilstyrelsen. Samtidig omfatter processen flere forskellige dokumenttyper og transformationer undervejs.
Figur 4 - Proces for produktion, behandling og publicering af lovforslag som fremsat af regeringen
ID |
Beskrivelse |
C.1 |
Minister udarbejder lovforslag En minister xxxxxxxxxx et lovforslag med bemærkninger og fremsættelsestale. Forslagsnummer modtages fra Folketingets Lovsekretariat og fremsættelsesdato konfereres med Lovsekretariatet. |
C.2 |
Lovforslag anmeldes (fremsættelse) Lovforslaget anmeldes af Folketingets formand i Folketingssalen, typisk ved starten af et møde. (Kan dog også efter aftale med Lovsekretariatet ske på et andet tidspunkt i mødet.) Umiddelbart efter anmeldelsen ændrer Lovsekretariatet status for forslaget i Folketingets registreringssystem (Tingdok). Dette bevirker, at lovforslaget som fremsat og fremsættelsestalen via Lex Dania klient publiceres på Folketingets hjemmesider (xxx.xx.xx og xxx.xxxxxxxxxxxxxxxxx.xx) og Retsinformation. Lovforslaget kan gå videre til 1. behandling. |
C.3 |
Lovteknisk gennemgang af lovforslaget som fremsat Efter fremsættelsen i Folketingssalen foretager Lovsekretariatet en lovteknisk og sproglig gennemgang af lovforslagets tekst og markerer rettelser i en printet version af lovforslaget. Gennemgangen omfatter ikke bemærkningerne. Efter at Folketingstidende har læst korrektur (C.4) samler Lovsekretariatet rettelserne i det dokument, Folketingstidende har korrekturlæst. |
C.4 |
Korrekturlæsning af lovforslag som fremsat Folketingstidende læser korrektur på lovforslaget som fremsat, markerer forslag til rettelser og sender disse til godkendelse i Lovsekretariatet. |
C.5 |
Renkorrektur oprettes En ”renkorrektur” er en særlig version af lovforslaget som fremsat, hvori eventuelle ortografiske og lovtekniske rettelser, der kan gennemføres uden ændringsforslag, er indført. Formålet med at udarbejde en renkorrektur er især at mindske antallet af ændringer, der skal indarbejdes ved udarbejdelsen af lovforslaget med eventuelle ændringsforslag efter 2. behandling. |
C.6 |
1. behandling af lovforslag som fremsat Her er der mulighed for at drøfte de store linjer i lovforslaget samt høre ministerens og de øvrige folketingsgruppers holdning til lovforslaget. Et forslag må normalt tidligst komme til 1. behandling 2 dage efter fremsættelsen, men der bør dog gå 5 dage. Folketinget (som parlament) kan med kvalificeret flertal beslutte at fravige 2-dagesfristen. |
C.7 |
Henvisning til udvalg Efter 1. behandling henvises lovforslaget normalt til udvalgsbehandling. (Kun i ganske særlige situationer går et lovforslag direkte fra 1. til 2. behandling uden udvalgsbehandling). |
C.8 |
Afgives betænkning eller stilles ændringsforslag? Under udvalgsbehandlingen afgør udvalget, om det vil afgive en betænkning, der kan indeholde ændringsforslag. Selv hvis der afgives betænkning, kan ministeren eller medlemmer af Folketinget efterfølgende stille ændringsforslag uden for betænkning. Udvalget kan afgive en tilføjelse til betænkning, hvis det inden 2. behandling vil supplere en allerede afgivet betænkning, f.eks. med nye oplysninger eller ændringsforslag. Betænkning, tilføjelse til betænkning og ændringsforslag uden for betænkning behandles ens, for så vidt angår den fremadrettede proces. |
C.9 |
Betænkning eller ændringsforslag uden for betænkning produceres og frigives Såfremt udvalget vælger at afgive en betænkning, er det udvalgssekretariatet, der udarbejder den. En betænkning kan indeholde følgende: En summarisk beskrivelse af udvalgets arbejde med forslaget. Folketingsgruppernes indstillinger, dvs. tilkendegivelser om, hvad de vil stemme. Eventuelle ændringsforslag til forslaget stillet af udvalgsmedlemmer eller af ministeren. Eventuelle politiske bemærkninger, dvs. udtalelser fra folketingsgrupperne, der forklarer, hvad de mener om lovforslaget og eventuelle ændringsforslag. Der kan også stilles ændringsforslag uden for betænkningen. Der er ikke formel forskel på ændringsforslag stillet i betænkningen og ændringsforslag, der stilles uden for betænkning. Betænkningen oprettes i Eunomia og sendes til korrektur i Folketingstidende (C.10). Når Folketingstidende har læst korrektur, indlæser og frigiver udvalgssekretariatet betænkningen/ændringsforslagene i Lex Dania klient. |
C.10 |
Korrekturlæsning Udvalgssekretariatet danner via Eunomia en pdf-version af den opmærkede betænkning m.v. Folketingstidende læser korrektur på denne pdf-version. Rettelsesforslag påføres manuelt. Herefter indscannes filen (som pdf) og sendes retur til udvalgssekretariatet. De rettelsesforslag, som udvalgssekretariatet vil følge, indskrives via Eunomia, hvorefter betænkningen m.v. med rettelser indlæses i Lex Dania klient af udvalgssekretariatet. |
C.11 |
Indarbejd ændringer i renkorrektur (= udarbejdelse af versionen efter afstemningerne ved 2. beh.) Udvalgssekretariatet sender den frigivne betænkning m.v. i pdf-version til Lovsekretariatet, som vurderer, om der er stillet ændringsforslag, som det må påregnes bliver vedtaget ved 2. behandling. Lovsekretariatet opretter i Lex Dania klient en version ”efter 2. behandling”, og den eksporteres til redigering og åbnes i Eunomia. I denne Eunomia-fil indarbejder Lovsekretariatet via indredigeringsmodulet i Eunomia, de ændringsforslag, som Lovsekretariatet forventer vil blive vedtaget. Efter to interne kontroller indlæser Lovsekretariatet dokumentet i Xxx Xxxxx klient. |
C.12 |
Afgives beretning? Hvis udvalget vælger ikke at afgive en betænkning, kan det vælge at afgive en beretning. Hvis udvalget ikke gør det, slutter processen her. (Populært sagt = Xxxxx dør i udvalget). |
C.13 |
Beretning produceres og frigives Udvalgene benytter især beretninger, når et lovforslag ikke ønskes til afstemning om endelig vedtagelse i Folketingssalen, men hvor der under udvalgsarbejdet er opnået en vis enighed om emner relateret til lovforslaget eller en del af dette. Det er dog meget sjældent, at et folketingsarbejdet med et regeringslovforslag afsluttes med en beretning. Det er udvalgssekretariatet, der står for at udarbejde beretningen i Eunomia. Herefter sendes en pdf-udgave af beretningen til Folketingstidende med henblik på korrekturlæsning. Udvalgssekretariatet indskriver beretningen i Eunomia og indlæser den i Lex Dania klient. Når Folketingstidende har læst korrektur (C.14), henter udvalgssekretariatet beretningen i Lex Dania klient og tager stilling til de foreslåede korrekturrettelser (godkendelse/afvisning) og genindlæser og frigiver beretningen i Lex Dania klient. Herefter slutter processen. |
C.14 |
Korrekturlæsning Udvalgssekretariatet danner via Eunomia en pdf-version af den opmærkede beretning. Folketingstidende læser korrektur på denne pdf-version. Rettelsesforslag påføres manuelt. Herefter indskannes filen (som pdf) og sendes retur til udvalgssekretariatet. De rettelsesforslag, som udvalgssekretariatet vil følge, indskrives via Eunomia, hvorefter beretningen med rettelser indlæses i Lex Dania klient af udvalgssekretariatet. |
C.15 |
2. behandling af lovforslag og evt. ændringsforslag 2. behandling må normalt tidligst finde sted 2 dage efter at 1. behandling er afsluttet, og 2 dage efter at betænkningen er offentliggjort. Det tilstræbes dog, at der er et tidsrum på 5-6 dage mellem offentliggørelsen af betænkningen og 2. behandling. Folketinget (som parlament) kan med kvalificeret flertal beslutte at fravige de nævnte tidsfrister. |
C.16 |
Lovforslag efter 2. behandling frigives Lovsekretariatet lytter til 2. behandling i Folketingssalen og frigiver versionen lovforslaget ”efter 2. behandling”, der er forberedt på forhånd, jf. C.11, hvis der er produceret en sådan version (og ændringsforslagene er blevet vedtaget). |
C.17 |
Fornyet henvisning til udvalg? Efter 2. behandling besluttes det, om lovforslaget skal henvises til fornyet udvalgsbehandling. Hvis det ikke er tilfældet, går lovforslaget direkte til 3. behandling. (Over 90 pct. af lovforslagene går direkte fra 2. til 3. behandling). |
C.18 |
Afgives tillægsbetænkning m.v.? Hvis lovforslaget henvises til fornyet udvalgsbehandling kan udvalget vælge at afgive en tillægsbetænkning, der kan indeholde ændringsforslag, eller en mundtlig indstilling (C.23). (Mundtlig indstilling kan dog ikke benyttes, hvis der stilles ændringsforslag.) Som supplement til tillægsbetænkningen kan udvalget afgive en tilføjelse til en tillægsbetænkning, der også kan indeholde ændringsforslag. Ministeren og medlemmer af Folketinget (som parlament) kan også stille ændringsforslag uden for tillægsbetænkningen eller tilføjelsen til tillægsbetænkningen. |
C.19 |
Xxxxxxx der ændringsforslag til 3. behandling? Ministeren og medlemmer af Folketinget (som parlament) kan stille ændringsforslag til 3. behandling, også hvis lovforslaget ikke er henvist til fornyet udvalgsbehandling. |
C.20 |
Ændringsforslagsdokument produceres og frigives Såfremt udvalget vælger at afgive en tillægsbetænkning, er det udvalgssekretariatet, der udarbejder tillægsbetænkningen. En tillægsbetænkning kan indeholde følgende: En summarisk beskrivelse af udvalgets arbejde med forslaget. Folketingsgruppernes indstillinger, dvs. tilkendegivelser om, hvad de vil stemme. Eventuelle ændringsforslag til forslaget, stillet af udvalgsmedlemmer el- ler af ministeren. Eventuelle politiske bemærkninger, dvs. udtalelser fra folketingsgrupperne, der forklarer, hvad de mener om lovforslaget og eventuelle ændringsforslag. Der kan også stilles ændringsforslag uden for tillægsbetænkningen eller – hvis lovforslaget ikke har været henvist til fornyet udvalgsbehandling – ændringsforslag til 3. behandling. Det er yderst sjældent, at der laves beretninger efter 2. behandling. Denne del er således ikke illustreret i processen. Udvalgssekretariatet indskriver ændringsforslagsdokumentet i Eunomia. Når Folketingstidende har læst korrektur (C.21), indlæser og frigiver udvalgssekretariatet betænkningen/ændringsforslagene i Lex Dania klient. |
C.21 |
Korrekturlæsning (af ændringsforslagsdokumentet (tillægsbetænkning m.v.)) Udvalgssekretariatet danner via Lex Dania klient en pdf-version af det indskrevne ændringsforslagsdokument m.v. Folketingstidende læser korrektur på denne pdf- version. Rettelsesforslag påføres manuelt. Herefter indscannes filen (som pdf) og sendes retur til udvalgssekretariatet. De rettelsesforslag, som udvalgssekretariatet vil følge, indskrives via Eunomia, hvorefter ændringsforslagsdokumentet med rettelser genindlæses i Lex Dania klient af udvalgssekretariatet. |
C.22 |
Indarbejd ændringer i lovforslag efter 2. behandling (=udarbejdelse af versionen af lovforslaget som vedtaget) Udvalgssekretariatet sender ændringsforslagsdokumentet i pdf-version til Lovsekretariatet, som vurderer, om der er stillet ændringsforslag, som det må påregnes bliver vedtaget ved 3. behandling. I Lex Dania klient opretter Lovsekretariatet en version ”efter 2. behandling”, hvis en sådan ikke allerede er oprettet. En kopi af versionen ”efter 2. behandling” eksporteres fra Lex Dania klient, åbnes og transformeres til ”som vedtaget ved 3. behandling” i Eunomia. I denne Eunomia-fil indarbejder Lovsekretariatet via indredigeringsmodulet i Eunomia de eventuelle ændringsforslag, som Lovsekretariatet forventer vil blive vedtaget. Efter to interne kontroller indlæser Lovsekretariatet dokumentet i Xxx Xxxxx klient. |
C.23 |
Afgives mundtlig indstilling? Hvis et udvalg har fået et lovforslag henvist til fornyet udvalgsbehandling efter 2. behandling, kan udvalget i stedet for at afgive tillægsbetænkning afgive en mundtlig indstilling, ved at udvalgets formand fra talerstolen oplæser indstillingen fra de forskellige medlemmer i udvalget som start på 3. behandling. (Mundtlig indstilling kan kun anvendes, hvis udvalgsarbejdet afsluttes, uden at der stilles ændringsforslag.) Hvis udvalget hverken afgiver tillægsbetænkning eller mundtlig indstilling, slutter processen her. |
C.24 |
Lovforslag og evt. ændringsforslag 3. behandles Behandlingen i Folketingssalen foregår således, at der først forhandles og stemmes om eventuelle ændringsforslag, hvorefter der forhandles og stemmes om lovforslaget som helhed. 3. behandling må normalt tidligst finde sted 2 dage efter 2. behandling eller tidligst 2 dage efter offentliggørelse af eventuel tillægsbetænkning og tidligst 30 dage efter fremsættelsen. Dog kan Folketinget (som parlament) med kvalificeret flertal beslutte at fravige de nævnte tidsfrister. |
C.25 |
Vedtages lovforslaget? Her stemmes der om endelig vedtagelse af lovforslaget i den form, det har efter eventuel vedtagelse af ændringsforslag ved 3. behandling. Hvis lovforslaget ikke vedtages, slutter processen her. |
C.26 |
Lovforslaget underskrives Hvis lovforslaget vedtages, skal formanden for Folketinget eller en næstformand sammen med en tingsekretær underskrive lovforslaget. Dette sker på en udskrift af pdf-versionen fra Lex Dania klient. |
C.27 |
Lovforslaget som vedtaget ved 3. behandling frigives og sendes til regeringen Lovsekretariatet lytter til 3. behandling i Folketingssalen og frigiver versionen af lovforslaget ”som vedtaget ved 3. behandling”, der er forberedt på forhånd efter at underskrifterne, jf. C.26, er overført til Lex Dania klient. Derefter sendes lovforslaget til ressortministeren og Statsministeriet med henblik på stadfæstelse og kundgørelse. |
C.28 |
Lovforslaget transformeres til lov, forhåndsoptages og forberedes til stadfæstelse Ressortministeriet eksporterer en kopi af lovforslaget ”som vedtaget ved 3. behandling” fra Lex Dania klient, transformerer lovforslaget til lov i Eunomia og indlæser loven som et nyt dokument i Lex Dania klient. Loven påføres foreløbig metadata (fx journalnummer) og forhåndsoptages til kundgørelse ved at advisere Civilstyrelsen gennem Lex Dania klient og pr. mail. |
C.29 |
Når stadfæstet af Regenten anmodes om optagelse af loven i Lovtidende Stadfæstelse af love sker almindeligvis på statsråd, men kan også ske uden for statsråd. På dagen for stadfæstelsen informerer Kabinetsekretariatet ministeriet om, at loven er stadfæstet af Regenten. Ministeriet retter i Xxx Xxxxx klient stamkortet for loven fsva. underskriftsdato, underskriftssted, regent og minister, såfremt rettelse er nødvendig. På stamkortet påføres tillige eventuelle relationer til andre love. Herefter frigives dokumentet og anmodes om optagelse i Lovtidende, hvorefter rettighederne overgår til Civilstyrelsen. |
C.30 |
Lovteknisk og redaktionel gennemgang. Loven kundgøres i Lovtidende Civilstyrelsen læser lovteknisk og redaktionel korrektur på loven. Eventuelle spørgsmål eller bemærkninger drøftes med ressortministeriet. Civilstyrelsen tjekker bl.a. at loven stemmer overens med lovforslaget som vedtaget, at loven er opsat korrekt og at ministeriet har påført korrekt metadata og referencer. Civilstyrelsen kundgør loven på xxxxxxxxxx.xx dagen efter stadfæstelsen. |
Tabel 3 - Proces for produktion, behandling og publicering af lovforslag som fremsat af regeringen
4Funktionelle krav
Dette kapitel indeholder de afdækkede funktionelle krav til den moderniserede Lex Dania klient. Kravene indgår som grundlag for opstart af udviklingsforløbet og vil gennem udviklingsforløbet blive nedbrudt og præciseret yderligere til mere håndterbare krav, der kan udvikles i de enkelte sprints i udviklingsprocessen. Kravene er således beskrevet på et forholdsvist højt abstraktionsniveau, hvor der for nuværende ikke er foretaget en komplet afdækning af samtlige regler og detaljer, som skal indgå i den moderniserede Lex Dania klients processer og løsningsfunktionalitet.
4.1Læsevejledning til funktionelle krav
Nedenfor gives en kort indføring i den anvendte metode, som ligger til grund for afdækningen af de funktionelle krav.
4.1.1Den anvendte metode
Xxxxxx har valgt en modelbaseret tilgang til beskrivelse af de funktionelle krav. Tilgangen har til formål at skabe et overblik over, hvad den moderniserede Lex Dania klient skal kunne, samt afdække de funktionelle krav på et passende niveau forud for udviklingsfasen. Samtidig har tilgangen til hensigt at belyse de funktionelle krav fra et proces- og opgaveperspektiv i form af Epics (samling af user stories). Desuden udarbejdes en forretningsmæssig beskrivelse af de snitflader, der er behov for til udveksling af information til og fra Løsningen.
Med udgangspunkt i de forretningsprocesser, som Løsningen skal understøtte, beskrives Epics, der på et mere detaljeret niveau forholder sig til den ønskede funktionalitet. Dog er Epics beskrevet på så overordnet et niveau, at de må forventes at skulle nedbrydes i mindre user stories i udviklingsfasen. Desuden er ikke alle acceptkriterier og forretningsregler på nuværende tidspunkt afdækket.
Forretningsprocesser og Epics er inddelt i en række funktionelle temaer.
4.1.2Forretningsprocesser
De forretningsprocesser, som ønskes understøttet af Løsningen, er kort beskrevet for hvert tema.
Processerne er beskrevet for at give kontekst til de enkelte Epics og med det fokus at beskrive det, der sker i den moderniserede Lex Dania klient – enten automatisk, eller ved at en bruger betjener Løsningen (via brugergrænsefladen eller en af Løsningen eksponeret snitflade).
4.1.3Epics
En Epic anvendes til at beskrive behovet for funktionalitet på et mere detaljeret niveau end procesbeskrivelser og udgør den ”baseline”, som udviklingen af den moderniserede Lex Dania klient tager udgangspunkt i.
De beskrevne Epics skal betragtes som en samling af user stories, hvor alle detaljer og forretningsregler (f.eks. lovgivningsmæssige eller forvaltningsmæssige regler) ikke kan forventes at være medtaget.
De forskellige Epics forventes at blive nedbrudt til mindre backlog-emner, som bliver udviklet i sprints. Her kan et backlog-emne tage form af en user story.
Nedenfor er skabelonen til beskrivelse af Epics indsat, inkl. en kort vejledning til indholdet i hvert felt.
Epic |
Nr.: <Her tildeles Epic’en et unikt nummer> |
||
Tema: |
<Her er indsat navnet på det tema, som Epic’en indgår i> |
Str.: |
<For hver Epic er angivet en indikation af størrelsen i ”T-shirt sizes” (S/M/L). Størrelsen er et udtryk for Kundens bedste bud på den forventede kompleksitet af Epic’en> |
Beskrivelse |
|||
<En Epic anvender formuleringen ”Som en <aktør/rolle>, vil jeg <funktionalitet>, så jeg <værdi/formål>”. I nogle tilfælde, hvor en given Epic afvikles automatisk, kan Lex Dania klient selv være aktør til Epic’en> |
|||
Acceptkriterier |
|||
<Beskriver de overordnede betingelser, der skal være til stede, for at en Epic kan betragtes som opfyldt. I Udviklingsfasen skal projektteamet udfolde og præcisere acceptkriterierne yderligere> |
|||
Bemærkninger / afklaringer |
|||
<Indeholder evt. supplerende oplysninger til en given Epic af interesse for Leverandøren> |
|||
Tabel 4 - Skabelon til beskrivelse af Epics
4.1.4Snitfladebeskrivelser
På baggrund af de afdækkede forretningsprocesser og Epics udarbejdes en række snitfladebeskrivelser, som på et overordnet niveau beskriver de snitflader, der er behov for, til og fra den moderniserede Lex Dania klient.
Snitfladebeskrivelserne er udgangspunktet for den videre analyse i udviklingsfasen, hvor de konkrete snitflader defineres og udvikles.
4.2Brugerprofiler i den moderniserede Lex Dania klient
Brugere og deres rettighedsprofiler skal som udgangspunkt videreføres uændret fra den nuværende til den moderniserede Lex Dania klient, idet disse er udtryk for den underliggende ansvarsfordeling mellem informationsleverandørerne og Civilstyrelsen i regelarbejdet. Dog kan der være behov for mindre justeringer til de tilladte handlinger og indsigtsrettigheder hos rettighedsprofilerne.
Dette afsnit indeholder en oversigt over rettighedsprofilerne i Løsningen og en overordnet beskrivelse af, hvilken rolle, profilerne udfylder. For en nærmere beskrivelse af brugerprofilerne henvises der herudover til Bilag 03 (Beskrivelse af Kundens nuværende system – Xxx Xxxxx produktion og Statstidende) med tilhørende dokumentation, herunder til appendiks 03.21 Rettighedsmatrice
Rolle |
Beskrivelse |
|
Ministerium |
Sagsbehandler |
Sagsbehandleren er den almindelige ministeriebruger som indlæser, bearbejder og frigiver dokumenter. |
Optagelsesanmoder |
Optagelsesanmoderen kan, ud over det samme som en Sagsbehandler, også anmode om dokumenters optagelse i Lovtidende. Brugeren vil typisk verificere, at dokumentets indhold og metadata er korrekt, inden der optagelsesanmodes. |
|
Optagelsesanmoder light |
Optagelsesanmoder light er begrænset til alene kunne anmode om optagelse af dokumenter, der skal kundgøres i Lovtidende. |
|
Kontaktperson |
Kontaktpersonen har samme muligheder for at indlæse, bearbejde, frigive og optagelsesanmode, som Sagsbehandler og Optagelsesanmoder har. Derudover kan Kontaktpersonen vedligeholde visse lister på ressortområdet og rette i visse metadata for dokumenter, der allerede er frigivet til slutbrugersystemet. |
|
Ressortadministrator |
Ressortadministratoren opretter og administrerer brugerprofiler på eget ressortområde. Typisk har brugeren samtidig tildelt rettighedsprofilen Kontaktperson. |
|
Folketinget |
FT Sagsbehandler |
FT Sagsbehandleren indlæser, bearbejder og frigiver til slutbrugersystemet dokumenttyper på Folketingets ressort. |
FT Tidendebruger |
FT Tidendebrugeren indlæser og bearbejder dokumenttyper på Folketingets ressort, men kan ikke frigive til slutbrugersystemet. |
|
FT Superbruger |
FT Superbrugeren indlæser og bearbejder dokumenttyper på Folketingets ressort, og kan derudover se visse oversigter og skifte folketingssamling. Profilen kan også ekstraordinært ajourføre dokumenter, som er frigivet. Desuden administrerer profilen brugere af typen: FT Sagsbehandler, FT Tidendebruger, FT Superbruger. |
|
Ombudsmand |
Ombudsmandsprofilen indlæser, bearbejder og frigiver til slutbrugersystemet de dokumenttyper, der er særlige for FOB. |
|
Civilstyrelsen |
CST Bruger |
CST Brugeren har en begrænset adgang til at fremsøge og bearbejde dokumenter på alle ressortområder (dog kun adgang til at se FT dokumenter). Profilen bruges af ansatte hos Civilstyrelsen, der benytter Lex Dania klient til den almindelige arbejdsgang med publicering og kundgørelse af dokumenter, men som endnu ikke har brug for superbrugerrettighederne. |
CST Superbruger |
CST Superbrugeren har, udover de rettigheder, CST Brugeren har, adgang til at adgang til brugerstyring, jobkørsel, ressortadministration og andre administrative funktioner. Profilen kan også se audit logs i Lex Dania klient. En CST Superbruger kan oprette brugere med følgende brugerrettigheder: CST Bruger. CST Superbruger. FT Superbruger. Kontaktperson. Ombudsmand. Ressortadministrator. Profilen tildeles ansatte (typisk juridiske fuldmægtige) hos Civilstyrelsen, som skal have det størst mulige sæt af rettigheder i løsningen. |
|
Tabel 5 - Oversigt over brugerprofiler i Lex Dania klient
4.3Dokumenttyper og dokumentstatus
Dokumentgange i Lex Dania produktion, er hovedsageligt styret af dokumenttyperne og deres dokumentstatus. Dokumenttyper og dokumentstatusser skal som udgangspunkt videreføres uændret fra den nuværende til den moderniserede Lex Dania klient. Dog kan det ikke udelukkes, at der vil blive behov for mindre justeringer i statusregimet i forbindelse med udviklingen af Løsningen.
Dokumenttyperne kan være tilknyttet en af følgende statusser beskrevet i afsnit 4.3.1 - 4.3.2 umiddelbart under.
4.3.1Regler og afgørelser
4.3.1.1Under behandling i ministeriet
Oprettet (Ministerium): Denne status påføres dokumenter, når de indlæses i Lex Dania klient. Status skifter dog med det samme til ”Under bearbejdning”.
Under bearbejdning (Ministerium): Denne status omfatter dokumenter med igangværende indrapportering af konsekvensrettelser eller redaktionelle oplysninger i Lex Dania klient, samt dokumenter, der har været eksporteret fra Lex Dania klient til Eunomia med henblik på redigering, og som derpå er genindlæst i Lex Dania klient.
Under redigering (Ministerium): Denne status omfatter dokumenter, der er eksporteret (det vil sige sendt tilbage) fra Lex Dania klient til Eunomia med henblik på redigering af dokumenternes tekst.
Klar til brugersystem (Ministerium): Denne status omfatter dokumenter uden retsvirkning, der er frigivet, men som stadig afventer den næste ajourføring af brugersystemet.
Frigivet (Ministerium): Denne status omfatter dokumenter med retsvirkning, hvor alle krævede konsekvensrettelser og redaktionelle oplysninger er indrapporteret i Lex Dania klient, og hvor dokumentet er frigivet, men endnu ikke anmodet om optagelse.
4.3.1.2Efter frigivelse fra ministeriet
Optagelsesanmodet: Denne status omfatter dokumenter med retsvirkning, der er færdigbehandlet af ministeriet og hvor en anmodning er afsendt om optagelse med henblik på kundgørelse henholdsvis offentliggørelse i slutbrugersystemet.
Under bearbejdning (CST): Denne status omfatter dokumenter, der er under bearbejdning af Civilstyrelsen, men som endnu ikke er overført til slutbrugersystemet. Civilstyrelsens bearbejdning består primært i indrapportering af data vedrørende kundgørelsen af dokumenter på xxxxxxxxxx.xx.
Under redigering (CST): Denne status omfatter dokumenter, der af Civilstyrelsen er eksporteret til Eunomia med henblik på Civilstyrelsens redigering af brødtekst, f.eks. i forbindelse med tildeling af lovnummer. Når dokumentet genindlæses i Lex Dania klient, efter redigering af brødtekst, får dokumentet status Under redigering (CST).
Klar til brugersystem: Denne status omfatter dokumenter med retsvirkning, der er færdigbehandlet af Civilstyrelsen, men som stadig afventer den næste ajourføring, der så vil medføre at dokumenterne automatisk overføres til slutbrugersystemet.
I brugersystem: Denne status omfatter dokumenter, der ligger i slutbrugersystemet.
Arkiveret: Denne status omfatter lovforslag i 2. behandling, idet disse ikke publiceres.
4.3.2Lov- og beslutningsforslag
Oprettet: Denne status påføres dokumenter, når de indlæses i Lex Dania klient. Status skifter dog med det samme til ”Under bearbejdning”.
Under bearbejdning: Denne status omfatter dokumenter, der er indlæst i Lex Dania klient, men endnu ikke er frigivet, samt dokumenter, der har været eksporteret fra Lex Dania klient til Eunomia med henblik på redigering af dokumentets tekst, og som efterfølgende er genindlæst i Lex Dania klient.
Under redigering: Denne status omfatter dokumenter, der er eksporteret (det vil sige sendt tilbage) fra Lex Dania klient til Eunomia med henblik på redigering af dokumentets tekst.
2. behandling oprettet: Denne status påføres dokumenttypen Renkorrektur, når der er oprettet et lovforslag til 2. behandling på baggrund af renkorrekturen.
Frigivet: Denne status omfatter dokumenter, der er færdigbehandlet af ministeriet eller Folketinget med henblik på indlæggelse i slutbrugersystemet.
Klar til brugersystem: Denne status omfatter dokumenter, der er færdigbehandlet og frigivet, men som afventer den næste ajourføring, således at dokumenterne overføres til slutbrugersystemet.
I brugersystem: Denne status omfatter dokumenter, der ligger i slutbrugersystemet.
Arkiveret: Denne status omfatter lovforslag i 2. behandling, idet disse ikke publiceres.
Afgjort: Denne status påføres dokumenttypen Aktstykke, når det er færdigbehandlet i Folketingets Finansudvalg.
4.4Tema 1 – Brugeradministration
Dette afsnit indeholder krav til brugeradministrationen i den moderniserede Lex Dania klient.
Brugeradministration i Løsningen indebærer oprettelse, redigering og sletning af brugere. Administrationen omfatter angivelse af brugeroplysninger som navn, ressort, rettighedsprofiler m.v.
4.4.1Processer for brugeradministration
Når informationsleverandørerne, herunder ministerier, Civilstyrelsen eller Folketinget får nye medarbejdere, der skal bruge løsningen, skal der oprettes en personlig bruger til vedkommende. Her går en administrator ind i Lex Dania klient og opretter en bruger til det respektive domæne.
Når en medarbejder fratræder, skifter navn eller får en anden rolle, skal en administrator igen ind og redigere eller slette brugeren.
Epic 01 – Administration af brugere (CST Superbruger)
Epic |
Nr.: |
01 |
|
Str.: |
L |
Tema: |
Brugeradministration |
||||
Beskrivelse |
|||||
Som CST Superbruger skal jeg kunne administrere brugere og deres rettighedsprofiler. |
|||||
Acceptkriterier |
|||||
Superbrugeren skal kunne oprette en bruger og tildele rettigheder. Superbrugeren skal kunne redigere en oprettet bruger og dets rettigheder. Superbrugeren skal kunne deaktivere og slette en bruger. Superbrugeren skal kunne oprette administratorer til ministerierne og Folketinget, jf. afsnit 4.2 (Brugerprofiler i den moderniserede Lex Dania klient). |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 02 – Administration af brugere (Decentralt på ressortniveau)
Epic |
Nr.: |
02 |
|
Str.: |
M |
Tema: |
Brugeradministration |
||||
Beskrivelse |
|||||
Som administrator (FT Superbruger, Ressortadministrator) skal jeg kunne foretage brugeradministration. |
|||||
Acceptkriterier |
|||||
Administratoren skal kun kunne oprette brugere under eget domæne jf. afsnit 4.2 (Brugerprofiler i den moderniserede Lex Dania klient) og tildele rettigheder. Administratoren skal kunne redigere en oprettet bruger og dets rettigheder. Administratoren skal kunne deaktivere og slette en bruger. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
4.5Tema 2 – Administration
Dette afsnit indeholder funktionelle krav til Administration i den moderniserede Lex Dania klient.
Ved Administration forstås konfiguration og vedligehold af lister og registre m.v., som skal understøttes af Løsningen og som varetages enten centralt hos Kunden eller decentralt af andre brugerprofiler. Derudover forstås ved Administration adgangen til at overvåge og administrere central funktionalitet, herunder adgang til joboversigter og referenceadministration.
4.5.1Processer for Administration
Adgang til administrativ funktionalitet er central for udførelsen af den løbende vedligeholdelse af data og processer i Løsningen. Civilstyrelsen fungerer som primær aktør i relation til administrationen, men også andre brugerprofiler har adgang til at tilgå visse administrative funktioner.
Sker der ændringer i ressortministeriernes sammensætning eller navneændringer, skal der øjeblikkeligt kunne tilrettes i myndighedslister m.v., således at Løsningen understøtter den nye virkelighed. Tilretning foretages af Civilstyrelsen og sker med udgangspunkt i de kongelige resolutioner, hvori forretningernes fordeling mellem ministrene officielt fastsættes.
Civilstyrelsen ajourfører dokumenter og deres metadata for dokumenter i tilstande, som kun Civilstyrelsen har adgang til at ændre i, navnlig dokumenter, der er i slutbrugersystemet. Heriblandt administrerer Civilstyrelsen referencerne til og fra dokumenter.
Derudover indgår det i Civilstyrelsens daglige arbejde, at overvåge jobkørsler og reagere på jobfejl, der f.eks. kan betyde, at dokumenter ikke er publiceret korrekt og derfor kræver yderlige undersøgelse eller handling hos Leverandøren. Jobkørslerne tjekkes typisk fast hver dag i forbindelse med bestilling af kundgørelser i Lovtidende.
Notifikationer og driftsmeddelelser benyttes til at advisere brugere i Løsningen og slutbrugere omkring nye funktioner, servicevinduer m.v.
Epic 03 – Vedligeholdelse af lister
Epic |
Nr.: |
03 |
|
Str.: |
M |
Tema: |
Administration |
||||
Beskrivelse |
|||||
Som bruger med de fornødne rettigheder skal jeg kunne vedligeholde redigerbare lister og registre. |
|||||
Acceptkriterier |
|||||
Bruger skal kunne rette i listen med ministerområder. Xxxxxx skal kunne rette i listen med myndigheder. Xxxxxx skal kunne rette i listen med Lovtidende emneord. Bruger skal kunne rette i FOB lister, herunder ministerområder, adm. områder, lovregister og emneord. Xxxxxx skal kunne rette i lister for Offentlighedsportalen. Xxxxxx skal kunne rette i listen med resolutioner. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 04 – Ajourføring af metadata
Epic |
Nr.: |
04 |
|
Str.: |
S |
Tema: |
Administration |
||||
Beskrivelse |
|||||
Som bruger med de fornødne rettigheder skal jeg kunne ajourføre metadata på dokumenter i slutbrugersystemet. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne ændre metadata, der ikke er låst som følge af dokumenttypen og dets tilstand. Ændringer skal gemmes i dokumentstatusloggen. Ændringer skal slå igennem på relevante frontends. |
|||||
Bemærkninger / Afklaringer |
|||||
Det kan f.eks. være oplysninger som populærtitel, redaktionelle noter eller andet der ændres. |
|||||
Epic 05 – Ekstraordinær ajourføring af dokumenter
Epic |
Nr.: |
05 |
|
Str.: |
S |
Tema: |
Administration |
||||
Beskrivelse |
|||||
Som bruger med de fornødne rettigheder skal jeg kunne ekstraordinært ajourføre dokumenter til brugersystemet, så jeg ikke skal afvente eventuelle faste jobkørsler. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne ekstraordinært ajourføre dokumenter, der er frigivet og ligger ”klar til brugersystem”. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 06 – Ophæv lås
Epic |
Nr.: |
06 |
|
Str.: |
S |
Tema: |
Administration |
||||
Beskrivelse |
|||||
Som bruger med de fornødne rettigheder skal jeg kunne låse dokumenter op, så det igen kan bearbejdes. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne ophæve låsen for dokumenter, der er eksporteret til redigering til LDe Eunomia. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 07 – Referencestyring
Epic |
Nr.: |
07 |
|
Str.: |
L |
Tema: |
Administration |
||||
Beskrivelse |
|||||
Som CST Superbruger vil jeg kunne administrere referencer påført et dokument. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne se et overblik over referencer til og fra et dokument. Xxxxxxxx skal kunne fjerne en reference på et dokument. Xxxxxxxx skal kunne omdanne/erstatte en reference på et dokument. |
|||||
Bemærkninger / Afklaringer |
|||||
Ved erstatning af referencer, skal brugeren blive advaret om de risici det indebærer. |
|||||
Epic 08 – Ressortomlægning
Epic |
Nr.: |
08 |
|
Str.: |
L |
Tema: |
Administration |
||||
Beskrivelse |
|||||
Som CST Superbruger skal jeg kunne foretage ressortomlægning. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne omlægge dokumenter fra et ressort til et andet. Brugeren skal kunne se, hvilke dokumenter, der bliver berørt ved ressortomlægningen. Brugeren skal på en overskuelig måde kunne vælge, hvilke dokumenter (med eventuelle tilknyttede dokumenter), der skal indgå i ressortomlægningen. Brugeren skal kunne omlægge en stor mængde (tusindvis) dokumenter på en gang. Brugeren skal kunne se tidligere ressortomlægninger med de berørte dokumenter. Brugeren skal kunne se ressorthistorik for hvert enkelt dokument. |
|||||
Bemærkninger / Afklaringer |
|||||
Ressortomlægningen skal visualiseres på en måde, der gør det nemt for brugeren at få et overblik over og til/fravælge, hvilke dokumenter der bliver berørt af omlægningen. |
|||||
Epic 09 – Notifikationer og driftsmeddelelser
Epic |
Nr.: |
09 |
|
Str.: |
S |
Tema: |
Administration |
||||
Beskrivelse |
|||||
Som CST Superbruger skal jeg kunne oprette og administrere notifikationer og driftsmeddelelser til brugergrænseflade og slutbrugersystem, så bruger og slutbrugere kan gøres opmærksom på nyheder, servicevinduer m.v. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne angive notifikationer og driftsmeddelelser med minimum titel og brødtekst. Brugeren skal kunne sætte en start og stop dato og tidspunkt for visningen af notifikationer og driftsmeddelelser. Brugeren skal kunne fjerne notifikationer og driftsmeddelelser, uanset om sluttidspunktet er nået. Brugeren skal kunne vælge, om notifikationen skal vises i brugergrænseflade og/eller i slutbrugersystem, og i så fald på hvilke websteder. |
|||||
Bemærkninger / Afklaringer |
|||||
Slutbrugersystemet omfatter alle websites tilknyttet Lex Dania produktion. |
|||||
Epic 10 – Joboversigt
Epic |
Nr.: |
10 |
|
Str.: |
M |
Tema: |
Administration |
||||
Beskrivelse |
|||||
Som CST Superbruger skal jeg kunne se oversigt over alle jobs, der er kørt, kører og/eller er fejlet. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne se kørselsstart og slut for hvert jobbundt. Brugeren skal kunne se status for kørsler i hvert jobbundt. Brugeren skal kunne se oplysninger om fejlede jobs og fejlbeskeder. Brugeren skal kunne se detaljeret afviklingslog for de enkelte jobbundter. Fejl og advarsler skal beskrives fyldestgørende og let forståeligt. |
|||||
Bemærkninger / Afklaringer |
|||||
De forskellige jobs afvikles i enten Hangfire eller som en Windows service. |
|||||
4.6Tema 3 – Indlæsning og eksportering
Indlæsning og eksportering af dokumenter er den manuelle kommunikation mellem dokumentredigeringsprogrammet LDe Eunomia og Xxx Xxxxx klient.
4.6.1Processer for indlæsning og eksportering
Alle dokumenter i produktionssystemet (med ganske få undtagelser) starter med at blive udarbejdet i LDe Eunomia, hvor dokumenttypen fastlægges, hvorved dokumentet opmærkes i den dokumentstruktur, som dokumenttypen bestemmer.
Ved f.eks. et nyt lovforslag udarbejder et ministerium dokumentet i LDe Eunomia baseret på den valgte dokumenttype. Ministeriet førstegangsindlæser herefter det udarbejdede dokument (ldex-fil) i Xxx Xxxxx klient.
Viser det sig, at dokumentet skal redigere – enten fordi, der er fejl i dokumentets indhold, eller fordi der skal ske andre justeringer i dokumentet - kan det eksporteres til redigering, hvorefter det låses i Lex Dania klient, så andre ikke kan eksportere/redigere det.
Efter dokumentet er tilrettet i LDe Eunomia, indlæses det på ny som et redigeret dokument, hvorved det erstatter den tidligere version af dokumentet. Dokumentet låses samtidig op igen, så metadata kan redigeres igen.
Informationsleverandørerne benytter sig ofte af strukturen i allerede indlæste dokumenter som basis for nye dokumenter. Således kan der f.eks. eksporteres en kopi af en bekendtgørelse til brug for udarbejdelsen af en ny bekendtgørelse. Dette vil typisk være hensigtsmæssigt i de tilfælde, hvor en ny bekendtgørelse skal erstatte en eksisterende, og hvor den nye i det væsentligste indholdsmæssigt ligner den eksisterende. Den eksporterede ldex-fil bearbejdes i LDe Eunomia og indlæses i Lex Dania klient som et nyt dokument.
Dokumenter som er frigivet til slutbrugersystemet, kan som udgangspunkt ikke eksporteres til redigering, men alene til kopi.
Epic 11 – Førstegangsindlæsning
Epic |
Nr.: |
11 |
|
Str.: |
L |
Tema: |
Indlæsning og eksportering |
||||
Beskrivelse |
|||||
Som bruger med rettigheder til indlæsning, vil jeg kunne førstegangsindlæse en ldex-fil, hvorefter dokumentet får status "Oprettet" efterfulgt af status "Under bearbejdning". |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne fremsøge og vælge et dokument (ldex-fil) på deres lokale maskine. Brugeren skal kun kunne fremsøge gyldige dokumenttyper. Brugeren skal automatisk navigeres ind i mappen, der er gemt i deres personlige konfiguration. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 12 – Eksportering til redigering
Epic |
Nr.: |
12 |
|
Str.: |
S |
Tema: |
Indlæsning og eksportering |
||||
Beskrivelse |
|||||
Som bruger med rettigheder til eksportering, vil jeg kunne eksportere et dokument til redigering, som er i en tilstand, hvor den må eksporteres, hvorefter at dokumentet får status "Under redigering". |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne eksportere et dokument til redigering fra den moderniserede Lex Dania klient. Dokumentet skal låses ved eksportering, så det ikke kan redigeres af andre. Løsningen skal automatisk gemme det eksporterede dokument i mappen, der er gemt i deres personlige konfiguration. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 13 – Indlæsning af redigeret dokument
Epic |
Nr.: |
13 |
|
Str.: |
M |
Tema: |
Indlæsning og eksportering |
||||
Beskrivelse |
|||||
Som bruger med rettigheder til indlæsning, vil jeg kunne indlæse en redigeret ldex-fil, hvorefter dokumentet får status "Under bearbejdning". |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne fremsøge og vælge et dokument på deres lokale maskine. Brugeren skal kunne fremsøge og udpege det dokument, som det redigerede dokument skal erstatte. Brugeren skal automatisk navigeres ind i mappen, der er gemt i deres personlige konfiguration. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 14 – Eksportering af kopi
Epic |
Nr.: |
14 |
|
Str.: |
S |
Tema: |
Indlæsning og eksportering |
||||
Beskrivelse |
|||||
Som bruger med rettigheder til eksportering vil jeg kunne eksportere et dokument til kopi, hvorefter dokumentet ikke skifter status. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne eksportere et dokument som kopi fra den moderniserede Lex Dania klient. Løsningen skal automatisk gemme det eksporterede dokument i mappen, der er gemt i deres personlige konfiguration. |
|||||
Bemærkninger / Afklaringer |
|||||
Ved eksportering til kopi, skal dokumentet ikke låses i Lex Dania klient. |
|||||
Epic 15 – Indlæsning af andre filtyper end ldex
Epic |
Nr.: |
15 |
|
Str.: |
M |
Tema: |
Indlæsning og eksportering |
||||
Beskrivelse |
|||||
Som bruger med de fornødne rettigheder skal jeg kunne indlæse filtypen Oversigt.xml (Skats store vejledning) eller en PDF-fil (Bevillingslove). |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne indlæse en fil med navnet Oversigt.xml fra deres lokale maskine. Brugeren skal kunne indlæse en PDF-fil, som automatisk vil få dokumenttypen LTB (Lovtidende B). |
|||||
Bemærkninger / Afklaringer |
|||||
Det bemærkes, at Skats store vejledninger indlæst som Oversigt.xml ikke har været benyttet i en årrække. Funktionen skal dog fortsat understøttes, idet det ikke kan udelukkes, at der fremadrettet vil være et behov for at kunne indlægge store vejledninger i oversigtsform. LTB-dokumenter er den eneste dokumenttype, der skal kundgøres i Lovtidende B, som indeholder bevillingslovene, dvs. finanslove, tillægsbevillingslove og midlertidige bevillingslove. |
|||||
4.7Tema 4 – Dokumentsøgning
Dokumentsøgning er omdrejningspunktet for bearbejdningen af dokumenter i Løsningen, idet alle dokumenter i databasen let skal kunne fremsøges og identificeres.
4.7.1Processer ved dokumentsøgning
Informationsleverandørerne og Civilstyrelsen vil i det daglige arbejde løbende have behov for at fremsøge dokumenter i Løsningen i forbindelse med, at dokumenter skal bearbejdes, redigeres, frigives, optagelsesanmodes osv. For den daglige bruger er en effektiv dokumentsøgning et vigtigt værktøj til i procesunderstøttelsen.
Brugerne vil, alt efter hvilke oplysninger brugeren kender om dokumentet, benytte sig af simple eller avancerede søgninger.
Epic 16 – Simpel dokumentsøgning
Epic |
Nr.: |
16 |
|
Str.: |
L |
Tema: |
Dokumentsøgning |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne foretage en simpel søgning efter dokumenter ud fra deres stamdata. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne udsøge dokumenter ved f.eks. nummer, år eller DocID. Søgefunktionen skal være funktionelt centralt placeret i brugergrænsefladen. Brugeren skal alene kunne fremsøge de dokumenter, brugerprofilen har rettigheder til at se. Søgeresultater skal præsenteres med relevante stamdataoplysninger eller efter brugerens personlige konfiguration. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkning. |
|||||
Epic 17 – Avanceret dokumentsøgning
Epic |
Nr.: |
17 |
|
Str.: |
L |
Tema: |
Dokumentsøgning |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne foretage en avanceret søgning efter dokumenter ud fra deres stamdata. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne foretage en avanceret søgning af dokumenter, hvor der kan filtreres på alle tilgængelige stamdataoplysninger. Brugeren skal alene kunne fremsøge de dokumenter, brugerprofilen har rettigheder til at se. Søgeresultater skal præsenteres med relevante stamdataoplysninger eller efter brugerens personlige konfiguration. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkning. |
|||||
Epic 18 – Visning af seneste fremsøgte dokumenter
Epic |
Nr.: |
18 |
|
Str.: |
S |
Tema: |
Dokumentsøgning |
||||
Beskrivelse |
|||||
Som bruger vil jeg hurtig kunne se mine senest fremsøgte dokumenter. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne se senest fremsøgte dokumenter. |
|||||
Bemærkninger / Afklaringer |
|||||
Dette er ikke en funktion, der findes i den nuværende Lex Dania klient. |
|||||
Epic 19 – Gem søgekriterier
Epic |
Nr.: |
19 |
|
Str.: |
S |
Tema: |
Dokumentsøgning |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne gemme søgekriterier. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne gemme søgekriterier. Brugeren skal kunne tilgå gemte faste/favorit søgninger. |
|||||
Bemærkninger / Afklaringer |
|||||
Dette er ikke en funktion, der findes i den nuværende Lex Dania klient. |
|||||
4.8Tema 5 – Dokumentbearbejdning
Dokumentbearbejdning er betegnelsen for alle de handlinger, der knytter sig til bearbejdningen af dokumenter i den moderniserede Lex Dania klient og som ikke er ændringer til de indholdsmæssige dele, som LDe Xxxxxxx er ansvarlig for. Dokumentbearbejdningen omfatter indrapportering af stamdataoplysninger, redaktionelle oplysninger og referencer.
4.8.1Processer for dokumentbearbejdning
Dokumentbearbejdning foretages af Informationsleverandørerne, som beriger indlæste dokumenter med en række oplysninger. Visse oplysninger, som f.eks. journalnummer, underskriftssted og underskriftsdato, ”brændes” ind på selve dokumentet. Andre oplysninger præsenteres alene som metadata i backend og i slutbrugersystemet.
Som led i dokumentbearbejdningen påfører Informationsleverandørerne også referencer til andre dokumenter i databasen. Eksempelvis kan en lov ændre eller ophæve andre love. Referencerne håndteres ved publiceringen af konsekvensberegneren, og bruges til at vise relationerne imellem dokumenterne på xxxxxxxxxxxxxxx.xx i form af links og tidslinjevisninger. Referencesystemet og konsekvensberegneren er nærmere beskrevet i Bilag 03a (Teknisk beskrivelse af Xxx Xxxxx klient), afsnit 5.3-5.4. Det forudsættes, at referencesystemet og konsekvensberegneren videreføres og anvendes uændret i den moderniserede Lex Dania klient.
Undervejs i bearbejdningen tjekker brugeren løbende, hvordan de indrapporterede oplysninger påvirker de endelige dokumentvisninger, som omfatter visninger i PDF’er og HTML.
Når et dokument er færdigbearbejdet frigiver brugeren dokumentet til slutbrugersystemet. Dvs. at dokumentet offentliggøres på de relevante frontends tilknyttet produktionssystemet. Er der tale om en dokumenttype, der skal kundgøres i Lovtidende, kan brugeren ikke frigive direkte til brugersystemet men kan anmode om optagelse i Lovtidende, hvorefter behandlingen overgår til Civilstyrelsen. I forbindelse med optagelsesanmodningen, sender informationsleverandøren en e-mail til Civilstyrelsen med kontaktoplysninger på den person, Civilstyrelsen kan rette henvendelse til med eventuelle bemærkninger eller spørgsmål forud for kundgørelsen.
Epic 20 – Visning af dokumentoplysninger
Epic |
Nr.: |
20 |
|
Str.: |
S |
Tema: |
Dokumentbearbejdning |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne få vist alle dokumentoplysninger tilhørende et dokument. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne se alle metadata tilknyttet dokumentet, hvad enten de er medfødt fra det indlæste dokument eller indrapporteret via Løsningen. Xxxxxxxx skal kunne se alle indrapporterede stamdata, referencer og redaktionelle oplysninger. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 21 – Indrapportering af stamdata
Epic |
Nr.: |
21 |
|
Str.: |
M |
Tema: |
Dokumentbearbejdning |
||||
Beskrivelse |
|||||
Som bruger skal jeg kunne påføre og redigere i stamdata for et dokument. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne påføre stamdata til et dokument. Dokumenttypen skal være bestemmende for, hvilke typer stamdataoplysninger, der kan påføres. Xxxxxxxx skal kunne redigere i stamdata til et dokument. Brugerens adgang til at påføre og redigere stamdata skal afhænge af brugerens rettigheder og dokumentets tilstand. Xxxxxxxx skal kunne overføre udvalgte stamdata fra et eksisterende dokument til et nyt dokument, når det nye dokument oprettes på baggrund af det eksisterende dokument. |
|||||
Bemærkninger / Afklaringer |
|||||
Metadata, der stammer fra den indlæste ldex-fil, herunder forfatter, titel, dokumenttype m.v. skal ikke kunne redigeres. |
|||||
Epic 22 – Indrapportering af redaktionelle oplysninger
Epic |
Nr.: |
22 |
|
Str.: |
M |
Tema: |
Dokumentbearbejdning |
||||
Beskrivelse |
|||||
Som bruger skal jeg kunne påføre og redigere redaktionelle oplysninger til et dokument. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne påføre oplysninger af redaktionel karakter, herunder stikord og redaktionelle noter. Xxxxxxxx skal kunne redigere i redaktionelle oplysninger til et dokument. Brugerens adgang til at påføre og redigere redaktionelle oplysninger skal afhænge af brugerens rettigheder og dokumentets tilstand. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 23 – Indrapportering af referencer
Epic |
Nr.: |
23 |
|
Str.: |
L |
Tema: |
Dokumentbearbejdning |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne påføre referencer fra et dokument til et andet, hvorved der automatisk sker de nødvendige konsekvensberegninger til etablering af referencer mellem de berørte dokumenter, og til historisk-markeringer m.v. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne påføre referencer fra et dokument til et andet i Løsningen. Xxxxxxxx skal alene kunne påføre referencer, der passer til dokumenttypen. Brugeren skal kunne redigere eller fjerne påførte referencer. Brugeren skal kunne påføre EU-referencer til EU-dokumenter. Brugeren skal kunne validere direkte i Løsningen, at det er det korrekte EU-dokument, der er refereret til. |
|||||
Bemærkninger / Afklaringer |
|||||
Validering af EU-referencer er ikke understøttet i den nuværende Lex Dania klient. |
|||||
Epic 24 – Preview af HTML
Epic |
Nr.: |
24 |
|
Str.: |
S |
Tema: |
Xxxxxxxxxx, anmodning om optagelse, nedskrivning og publicering |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne se et preview af dokumentet i HTML, så jeg kan se, hvordan dokumentet kommer til at se ud på xxxxxxxxxxxxxxx.xx. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne generere et preview i HTML. Previewet skal være en nøjagtig visning af dokumentets endelige udformning i slutbrugersystemet. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 25 – Preview af PDF
Epic |
Nr.: |
25 |
|
Str.: |
S |
Tema: |
Xxxxxxxxxx, anmodning om optagelse, nedskrivning og publicering |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne se et preview af dokumentet i de for dokumentet tilgængelige PDF-visninger. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne generere et preview som Lovtidende PDF. Brugeren skal kunne generere et preview som Retsinfo PDF. Brugeren skal kunne generere et preview som Folketingstidende PDF. Brugeren skal kunne generere et preview som Offentlighedsportalen PDF. Previewet skal være en nøjagtig visning af dokumentets endelige udformning i slutbrugersystemet. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 26 – Frigivelse
Epic |
Nr.: |
26 |
|
Str.: |
S |
Tema: |
Xxxxxxxxxx, anmodning om optagelse, nedskrivning og publicering |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne frigive et dokument, hvorefter yderligere bearbejdning af dokumentet afskæres, og så dokumentet offentliggøres på relevante hjemmesider. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne frigive et dokument. Xxxxxxxx skal ikke kunne rette i dokumentet efter frigivelse. Ved frigivelse skal dokumentet låses, så det ikke kan eksporteres til redigering. |
|||||
Bemærkninger / Afklaringer |
|||||
I den nuværende Lex Dania klient er frigivelse og anmodning om optagelse to selvstændige handlinger. Dokumenter der skal frigives til Folketinget og/eller til xxxxxxxxxxxxxxx.xx alene frigives direkte til slutbrugersystemet. Dokumenter, der skal kundgøres i Lovtidende, skal både frigives og optagelsesanmodes, jf. Epic 27, for at dokumentet kan viderebearbejdes af Civilstyrelsen. |
|||||
Epic 27 – Optagelsesanmodning
Epic |
Nr.: |
27 |
|
Str.: |
M |
Tema: |
Xxxxxxxxxx, anmodning om optagelse, nedskrivning og publicering |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne anmode om optagelse af et dokument, og få en kvittering for dette. Hvorefter dokumentet overføres til optagelseslisten til Civilstyrelsens videre foranstaltning. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne anmode om optagelse af dokumentet. Xxxxxxxx skal ikke kunne rette i dokumentet efter anmodningen. Ved optagelsesanmodning skal dokumentet låses, så det ikke kan eksporteres til redigering. Xxxxxxxx skal kunne angive en kommentar til Civilstyrelsen og kontaktoplysninger på den sagsbehandler, Civilstyrelsen kan kontakte, skulle styrelsen have eventuelle spørgsmål eller bemærkninger. |
|||||
Bemærkninger / Afklaringer |
|||||
I den nuværende Lex Dania klient er frigivelse og anmodning om optagelse to selvstændige handlinger. Dokumenter, der skal frigives til Folketinget og/eller til xxxxxxxxxxxxxxx.xx alene, frigives direkte til slutbrugersystemet. Dokumenter, der skal kundgøres i Lovtidende, skal frigives, jf. Epic 26, før de kan optagelsesanmodes og viderebearbejdes af Civilstyrelsen. |
|||||
4.9Tema 6 – Lovtidende redaktion og kundgørelse
Tema 6 omhandler processen forbundet med udgivelsen i Lovtidende af de dokumenter, som Informationsleverandørerne har anmodet om optagelse af.
4.9.1Processer for Lovtidende redaktion og kundgørelse
Dokumenter, som er retligt bindende forskrifter, skal kundgøres i Lovtidende inden de kan få virkning og håndhæves. Dokumenttyperne er love, bekendtgørelser, kongelige anordninger m.fl.
Når Informationsleverandøren har anmodet om optagelse af en forskrift, overgår rettighederne til Civilstyrelsen, som er udgiver af Lovtidende.
Civilstyrelsen læser lovteknisk korrektur på forskrifterne og efterser at alle metadata og referencer er indrapporteret korrekt. Derudover påføres Lovtidende emneord og andre redaktionelle oplysninger.
Hvis Civilstyrelsen har bemærkninger til forskriften, som gør at der skal ske rettelser, nedskrives forskriften til Informationsleverandøren, så vedkommende kan foretage rettelserne og anmode om optagelse på ny.
Civilstyrelsen bestiller fejlfrie forskrifter til kundgørelse i Lovtidende dagligt, hvis der er forskrifter til udgivelse. Udgivelsen af Lovtidende sker elektronisk på xxxxxxxxxx.xx, og forskrifterne offentliggøres samtidig på xxxxxxxxxxxxxxx.xx.
Epic 28 – Nedskrivning af dokument
Epic |
Nr.: |
28 |
|
Str.: |
S |
Tema: |
Lovtidende redaktion og kundgørelse |
||||
Beskrivelse |
|||||
Som CST-bruger vil jeg kunne nedskrive et dokument, hvorefter rettighederne skrives tilbage til Informationsleverandøren. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne nedskrive et dokument, hvis det er blevet anmodet om optagelse. Ved nedskrivning skal dokumentet igen kunne bearbejdes af Informationsleverandøren, så det f.eks. kan eksporteres til redigering. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 29 – Redaktionel bearbejdning
Epic |
Nr.: |
29 |
|
Str.: |
S |
Tema: |
Lovtidende redaktion og kundgørelse |
||||
Beskrivelse |
|||||
Som CST-bruger vil jeg have værktøjer til at danne mig overblik over og redaktionelt bearbejde optagelsesanmodede dokumenter. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne se en oversigt over alle optagelsesanmodede dokumenter. Brugerne skal kunne sortere dokumenterne efter relevante parametre. Xxxxxxxx skal kunne administrere dokumenter ved hjælp af f.eks. symbol- og farvemarkeringer, interne noter deslige. Xxxxxxxx skal kunne downloade den samlede liste over optagelsesanmodede dokumenter som csv til evt. viderebearbejdning uden for Løsningen. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 30 – Påføring af emneord
Epic |
Nr.: |
30 |
|
Str.: |
S |
Tema: |
Lovtidende redaktion og kundgørelse |
||||
Beskrivelse |
|||||
Som CST-bruger vil jeg kunne tilføje emneord til et dokument. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne vælge emneord fra emneordslisterne. Brugeren skal kun kunne vælge fra den emneordsliste, der svarer til den afdeling (A, B eller C) som den konkrete dokumenttype udgives i. |
|||||
Bemærkninger / Afklaringer |
|||||
Emneordslisten vedligeholdes af Civilstyrelsen i modsætning til stikordslisten, der vedligeholdes af de enkelte ressortministerier. |
|||||
Epic 31 – Overførsel af dokument
Epic |
Nr.: |
31 |
|
Str.: |
S |
Tema: |
Lovtidende redaktion og kundgørelse |
||||
Beskrivelse |
|||||
Som CST-bruger vil jeg kunne overføre dokumenter til ordinær og ekstraordinær kundgørelse. |
|||||
Acceptkriterier |
|||||
Brugeren med adgang til optagelseslisten skal kunne overføre dokumentet til ordinær listen. Brugeren med adgang til optagelseslisten skal kunne overføre dokumentet til ekstra ordinær listen. |
|||||
Bemærkninger / Afklaringer |
|||||
Det er kun CST brugere der overfører dokumenter til ordinær eller ekstra ordinær listen. |
|||||
Epic 32 – Simulering af konsekvensberegningen
Epic |
Nr.: |
32 |
|
Str.: |
L |
Tema: |
Lovtidende redaktion og kundgørelse |
||||
Beskrivelse |
|||||
Som CST-bruger vil jeg kunne foretage en simulering af konsekvensberegning af referencer. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne køre en simulation af konsekvensberegningen. Xxxxxxxx skal kunne se en detaljeret liste over konsekvenser. Listen over konsekvenser skal vise alle berørte dokumenter, og hvilke type konsekvenser referencerne vil have for de enkelte dokumenter. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 33 – Bestilling af kundgørelse
Epic |
Nr.: |
33 |
|
Str.: |
L |
Tema: |
Lovtidende redaktion og kundgørelse |
||||
Beskrivelse |
|||||
Som CST-bruger vil jeg kunne bestille kundgørelse for de dokumenter, der er overført til ordinær og ekstraordinær kundgørelse. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne bestille dokumenter til ordinær kundgørelse. Brugeren skal kunne bestille dokumenter til ekstraordinær kundgørelse. Dokumenterne skal automatisk tildeles fortløbende nummer fra nummerrullen. Det skal være muligt at ændre på bestillingsrækkefølgen og tildele numre manuelt. Xxxxxxxx skal få en udskrivningsvenlig kvittering for bestilling af en kundgørelse. |
|||||
Bemærkninger / Afklaringer |
|||||
Hver Lovtidende-afdeling (A, B og C) har sin egen nummerrulle som nulstilles hvert år. Lovtidendedokumenter identificeres derfor i almindelighed ved deres nummer og årstal. |
|||||
Epic 34 – Omtryk af dokument
Epic |
Nr.: |
34 |
|
Str.: |
M |
Tema: |
Lovtidende redaktion og kundgørelse |
||||
Beskrivelse |
|||||
Som CST-bruger vil jeg have mulighed for at foretage et omtryk af kundgjorte lovtidende-dokumenter og tilføje en omtryksnote. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne omtrykke et dokument, hvorved dokumentet genpubliceres med et redigeret indhold. Xxxxxxxx skal kunne tilføje en omtryksnote til det omtrykte dokument. Brugeren skal kunne sammenholde det oprindelige med det omtrykte dokument i Løsningen. |
|||||
Bemærkninger / Afklaringer |
|||||
Omtryk forekommer typisk omkring 10 gange på et år. Der foretages kun omtryk, hvis det er åbentyst, at der er tale om en fejl, hvis det er klart, hvad der skulle have stået i stedet, og hvis omtrykket kan laves i umiddelbar tidsmæssigt sammenhæng til den oprindelige kundgørelse. |
|||||
4.10Tema 7 – Sporbarhed og versionering
Xxx Xxxxx produktion er af Kunden kategoriseret som samfundskritisk i relation til model for porteføljestyring af statslige it-systemer, idet der er tale om kritisk retslig infrastruktur.
Dette betyder bl.a., at der skal være en høj grad af sporbarhed og versionering i Applikationerne, herunder i den moderniserede Lex Dania klient.
4.10.1Processer for sporbarhed og versionering
Sporbarhed og versionering er en væsentlig del af det daglige arbejde med de dokumenter, der indlæses og bearbejdes i Løsningen.
Brugerne vil løbende orientere sig i historikken og status for et dokument for at verificere, hvilke handlinger, der er udført på det pågældende dokument og hvem der har udført handlingen.
Dokumenter kan nå at foreligge i adskillige versioner inden den endelige udgave er klar til frigivelse og publicering. Dette skyldes, at dokumenter ofte indlæses i foreløbige versioner, som tilrettes efterhånden som dokumentets indhold lægges til godkendelse internt. Derudover kan eventuelle bemærkninger fra Civilstyrelsen, i forbindelse med dokumentets anmodning om optagelse i Lovtidende, føre til indholdsmæssige rettelser.
Som led i sporbarheden hos brugerne, vil der samtidig være behov for visse steder i dokumentflowet at få en bekræftelse/kvittering på, at en bestemt handling er udført. Bekræftelsen benyttes typisk til journalisering i ESDH-systemer uden for Løsningen.
Epic 35 – Visning af dokumentstatus og logs
Epic |
Nr.: |
35 |
|
Str.: |
M |
Tema: |
Sporbarhed og versionering |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne se et dokuments statushistorik, log og informationer fra den første indlæsning i Løsningen og frem til det aktuelle tidspunkt. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne se en log over et dokumentets statushistorik. Xxxxxxxx skal kunne se en log over handlinger påført dokument. Herunder skal det vises, hvilken bruger, der har udført handlingen. Xxxxxxxx skal kunne se en log over alle transaktioner vedrørende dokumentet, der er gennemført i dokumentets levetid. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 36 – Visning af tidligere dokumentversioner
Epic |
Nr.: |
36 |
|
Str.: |
L |
Tema: |
Sporbarhed og versionering |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne se tidligere og sammenligne versioner af dokumenter og se, hvilke ændringer til metadata, der har været. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne se tidligere versioner af et dokument. Brugeren skal kunne sammenligne to versioner af et dokument direkte i Løsningen. Forskelle skal være tydeligt markeret. Brugeren skal kunne se ændringer til metadata, herunder hvilken bruger, der har foretaget ændringerne. |
|||||
Bemærkninger / Afklaringer |
|||||
Dokumentversionering sker i nogen grad allerede i backend, men vises ikke i brugergrænsefladen i den nuværende Lex Dania klient. |
|||||
Epic 37 – Versionsstyring af dokumenter
Epic |
Nr.: |
37 |
|
Str.: |
L |
Tema: |
Sporbarhed og versionering |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne gendanne et dokument tilbage til en tidligere version, hvis dokumentets tilstand tillader det. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne vælge en tidligere version, der erstatter den seneste. Brugeren skal kunne eksportere tidligere versioner af et dokument som kopi til bearbejdning i LDe Eunomia. |
|||||
Bemærkninger / Afklaringer |
|||||
Dette er ikke en funktion, der findes i den nuværende Lex Dania klient. |
|||||
Epic 38 – Kvitteringer ved bestemte handlinger
Epic |
Nr.: |
38 |
|
Str.: |
M |
Tema: |
Sporbarhed og versionering |
||||
Beskrivelse |
|||||
Som bruger vil jeg have kvitteringer ved bestemte handlinger. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal få en kvittering ved bestemte handlinger. Kvitteringen skal kunne skrives/printes ud. |
|||||
Bemærkninger / Afklaringer |
|||||
Kunden bestemmer sammen med Leverandøren, hvilke handlinger, der skal generere en kvittering. |
|||||
Epic 39 – Overblik over tidligere bestilte kundgørelser
Epic |
Nr.: |
39 |
|
Str.: |
M |
Tema: |
Sporbarhed og versionering |
||||
Beskrivelse |
|||||
Som CST-bruger vil jeg kunne se et overblik over tidligere bestilte kundgørelser. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne se en log over kundgørelser, der er bestilt. Xxxxxxxx skal kunne se tidspunktet for bestillingen og hvem der har bestilt en kundgørelsen. Brugeren skal kunne se, hvilke dokumenter, der er omfattet af hver enkelt bestilling. Brugeren skal kunne se om kundgørelsen er bestilt som ordinær eller ekstraordinær kundgørelse. |
|||||
Bemærkninger / Afklaringer |
|||||
Dette er ikke en funktion, der findes i den nuværende Lex Dania klient. |
|||||
Epic 40 – Brugerlog
Epic |
Nr.: |
40 |
|
Str.: |
M |
Tema: |
Sporbarhed og versionering |
||||
Beskrivelse |
|||||
Som CST-Superbruger vil jeg kunne se en log over brugerhandlinger såsom log ind, log ud, ændring af kodeord m.v. |
|||||
Acceptkriterier |
|||||
Brugeren skal i loggen se, når en bruger har logget ind. Brugeren skal i loggen se, når en bruger har logget ud. Brugeren skal i loggen se, når en bruger har skiftet kodeord. Brugeren skal i loggen se, når en bruger har oprettet en anden bruger. Brugeren skal i loggen se, når en bruger har slettet en anden bruger. Brugeren skal i loggen se, når en bruger har redigeret en anden bruger. Brugeren skal i loggen se, når en bruger har nulstillet kodeordet for en anden bruger. Brugeren skal i loggen se, når en bruger har brugt et loginforsøg. |
|||||
Bemærkninger / Afklaringer |
|||||
Loggen skal vise, hvilken bruger, der har udført handlingen. Hvis handlingen vedrører en anden bruger, skal denne bruger også angives. |
|||||
4.11Tema 8 – Folketinget
Folketinget spiller en særlig rolle i Xxx Xxxxx produktion, idet en række dokumenttyper, handlinger og funktioner er særegne og direkte forbundet til Folketingets dokumentbearbejdning. I Tema 8 listes således de væsentligste funktionelle krav, som relaterer sig til Folketingets arbejde.
4.11.1Processer i Folketinget
Folketinget (som parlament) udgør, jf. grundlovens § 3, i forening med Kongen (=regeringen) den lovgivende magt. I den funktion behandler Folketinget (som parlament) lovforslag og beslutningsforslag. Lov- og beslutningsforslag kan fremsættes af regeringen, jf. grundlovens § 21, men også medlemmer af Folketinget kan fremsætte lov- og beslutningsforslag, jf. grundlovens § 41, stk. 1. Lovforslag kan ikke vedtages før de har været behandlet tre gange i Folketinget (som parlament), jf. grundlovens § 41, stk. 2. Det fleste beslutningsforslag undergår, jf. Folketingets (som parlament) forretningsorden, to behandlinger. Normalt vil forslagene blive behandlet i et af Folketingets (som parlament) stående udvalg mellem behandlingerne i Folketinget (som parlament). Ved nyvalg og ved folketingsårets udgang bortfalder forslag, der ikke forinden er endeligt vedtaget (eller forkastet), jf. grundlovens § 41, stk. 4.
Under Folketingets (som parlament) behandling kan forslagene undergå forandringer, hvis Folketinget (som parlament) vedtager ændringsforslag til de fremsatte forslag. De fleste ændringsforslag stilles i en såkaldt betænkning afgivet af det udvalg, der har behandlet forslaget, men kan også stilles uden for betænkning.
Til et lovforslag kan man behandle fire typer betænkninger: Betænkning, Tilføjelse til betænkning, Tillægsbetænkning, Tilføjelse til betænkning. Disse typer benyttes på forskellige tidspunkter for behandlingen af lovforslaget.
Folketinget (som parlament) og dets stående udvalg behandler også andre sagstyper af relevans for Xxx Xxxxx produktion: beretninger til lovforslag og beslutningsforslag, selvstændige beretninger, aktstykker og redegørelser.
De fleste funktioner i relation til Folketingets opgaver som nævnt ovenfor vil være dækket af de øvrige Epics i afsnit 4. Der er dog visse særegne funktioner, der er omfattet af følgende Epics nr. 41-46.
Epic 41 – Nedskrivning af dokument (FT)
Epic |
Nr.: |
41 |
|
Str.: |
M |
Tema: |
Folketinget |
||||
Beskrivelse |
|||||
Som bruger hos Folketinget vil jeg kunne nedskrive et dokument, hvorefter det igen kan bearbejdes. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne nedskrive et frigivet dokument, som er oprettet og indlæst af Folketinget, som udelukkende behandles på Folketingets domæne, og som endnu ikke er i brugersystemet. Ved nedskrivning skal dokumentet igen kunne bearbejdes, så det f.eks. kan eksporteres til redigering. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 42 – Behandling af styredokumenter
Epic |
Nr.: |
42 |
|
Str.: |
L |
Tema: |
Folketinget |
||||
Beskrivelse |
|||||
Som bruger hos Folketinget vil jeg kunne overvåge styredokumenter knyttet til sagsforløb.
|
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne åbne en log over styredokumenter. Xxxxxxxx skal kunne åbne et styredokument fra loggen.
|
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkning. |
|||||
Epic 43 – Navigering i sagsforløb
Epic |
Nr.: |
43 |
|
Str.: |
M |
Tema: |
Folketinget |
||||
Beskrivelse |
|||||
Som bruger vil jeg nemt kunne se, hvilke dokumenter der indgår i et sagsforløb og navigere imellem dokumenterne. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne administrere dokumenter i et sagsforløb. Brugeren skal blive guidet igennem sagsforløbets sagsskridt. Brugeren skal kunne transformere dokumenter i relevante sagsskridt, jf. Epic 44. |
|||||
Bemærkninger / Afklaringer |
|||||
Det skal fortsat være muligt manuelt at oprette dokumenter i et sagsforløb og i omvendt kronologi om nødvendigt. F.eks. ved hastelovgivning, hvor der efter omstændighederne vil være behov for at oprette ”lovforslaget som vedtaget” før ”lovforslaget efter 2. behandling” er frigivet. |
|||||
Epic 44 – Transformering af dokumenter
Epic |
Nr.: |
44 |
|
Str.: |
L |
Tema: |
Folketinget |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne transformere dokumenter som led i et sagsforløb hos Folketinget, så jeg kan undgå unødig bearbejdning af dokumentet i LDe Eunomia. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne transformere dokumentet fra én dokumenttype til en anden direkte i Løsningen. Xxxxxxxx skal kun have mulighed for at transformere til visse dokumenttyper og alene ved bestemte sagsskridt i sagsforløbet. |
|||||
Bemærkninger / Afklaringer |
|||||
Det skal fortsat være muligt manuelt at oprette dokumenter i et sagsforløb og i omvendt kronologi om nødvendigt. F.eks. ved hastelovgivning, hvor der efter omstændighederne vil være behov for at oprette ”lovforslaget som vedtaget” før ”lovforslaget efter 2. behandling” er frigivet. |
|||||
Epic 45 – Omtryk af dokument (FT)
Epic |
Nr.: |
45 |
|
Str.: |
M |
Tema: |
Folketinget |
||||
Beskrivelse |
|||||
Som bruger vil jeg have mulighed for at foretage et omtryk af offentliggjorte dokumenter. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne omtrykke et dokument, hvorved dokumentet genpubliceres med et redigeret indhold. Brugeren skal kunne påføre omtrykstitel og omtryksnote. Brugeren skal kunne sammenholde det oprindelige med det omtrykte dokument i Løsningen. |
|||||
Bemærkninger / Afklaringer |
|||||
Omtrykstitel påføres selve dokumentet i Folketingstidende. Omtryksnoten vises alene på xxxxxxxxxxxxxxx.xx |
|||||
Epic 46 – Skift folketingssamling
Epic |
Nr.: |
46 |
|
Str.: |
M |
Tema: |
Folketinget |
||||
Beskrivelse |
|||||
Som FT-Superbruger vil jeg kunne skifte folketingssamling, så der er fuld kontrol over, hvornår samlingen skal skifte. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne skifte folketingssamling. Ved skiftet skal der automatisk udføres de processer, som et folketingsskifte medfører. |
|||||
Bemærkninger / Afklaringer |
|||||
Skift af folketingssamling vil også skulle kunne foretages af en CST-Superbruger, men i praksis er det Folketinget, der påser, at samlingsskift sker på det rigtige tidspunkt. |
|||||
Epic 47 – Vedligeholdelse af lister (FOB)
Epic |
Nr.: |
47 |
|
Str.: |
S |
Tema: |
Folketinget |
||||
Beskrivelse |
|||||
Som bruger ved Folketingets Ombudsmand vil jeg kunne rette i FOB-lister og registre, så jeg løbende kan holde lister og registre ajour. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne rette i alle FOB lister og registre, herunder Ministerområder, Adm. Områder, lovregister og emneord. FOB-lister og registre skal kunne tilpasses ombudsmandens behov. |
|||||
Bemærkninger / Afklaringer |
|||||
Ombudsmanden placerer sine Udtalelser under særlige registre og emneordlister, hvis udformning og indhold er dikteret af ombudsmandens arbejde. |
|||||
4.12Tema 9 – Offentlighedsportalen
På xxxxxxxxxxxxxxxxxxxxx.xx indlægges alle love, administrative forskrifter og lovforslag og Folketingets Ombudsmands udtalelser om aktindsigt.
For dokumenter, der skal i Lovtidende og/eller offentliggøres på xxxxxxxxxxxxxxx.xx, er det en del af flowet, at Informationsleverandørerne vælger, hvorvidt dokumentet skal vises på Offentlighedsportalen.
Dokumenter, der af forskellige årsager alene skal indlægges på Offentlighedsportalen, oprettes som selvstændige OPO-dokumenter.
4.12.1Processer for OPO-dokumenter
Informationsleverandøren opretter OPO-dokumentet og opmærker det i LDe Eunomia. Indholdet kan f.eks. være et uddrag af en lov.
Dokumentet indlæses i Lex Dania klient som en hver anden ldex-fil og beriges med et særligt sæt af metadata. Dokumentet kan også tilknyttes andre dokumenter i databasen via dokumentreferencer. Herefter frigives dokumentet til slutbrugersystemet, hvorefter det offentliggøres på xxxxxxxxxxxxxxxxxxxxx.xx.
Epic 48 – OPO metadata
Epic |
Nr.: |
48 |
|
Str.: |
M |
Tema: |
Offentlighedsportalen |
||||
Beskrivelse |
|||||
Som bruger skal jeg kunne tilføje OPO metadata til et dokument, så det bliver kategoriseret korrekt på xxxxxxxxxxxxxxxxxxxxx.xx. |
|||||
Acceptkriterier |
|||||
Xxxxxxxx skal kunne påføre lov, kapitel og paragraf til dokumentet. Brugeren skal kunne påføre myndighed til dokumentet. Xxxxxxxx skal kunne påføre dokumentkategori til dokumentet. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 49 – Dokumentreferencer
Epic |
Nr.: |
49 |
|
Str.: |
M |
Tema: |
Offentlighedsportalen |
||||
Beskrivelse |
|||||
Som bruger skal jeg kunne oprette referencer fra et OPO-dokument til andre dokumenter. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne tilføje og fjerne referencer til andre dokumenter. |
|||||
Bemærkninger / Afklaringer |
|||||
Referencer til og fra et OPO-dokument skal ikke forveksles med referencer, der bruges i konsekvensberegningen. |
|||||
Epic 50 – Vedligeholdelse af OPO-lister
Epic |
Nr.: |
50 |
|
Str.: |
S |
Tema: |
Offentlighedsportalen |
||||
Beskrivelse |
|||||
Som CST-Superbruger skal jeg kunne vedligeholde listerne tilknyttet OPO-dokumenter, så listerne altid er opdaterede. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne listerne Lov, Kapitel og Paragraf. Xxxxxxxx skal kunne listen Myndighed. Xxxxxxxx skal kunne listen Dokumentkategori. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
4.13Tema 10 – Brugerhjælp og personlig konfiguration
Lex Dania produktion benyttes af brugere med forskellig uddannelsesmæssig baggrund, dog mestendels jurister og administrativt uddannede personer, i centraladministration og Folketinget.
Den moderniserede Lex Dania klient skal derfor udformes på en måde, så Løsningen er intuitiv, og så brugerne får den fornødne brugerhjælp i form af hjælpetekster, e-læringsværktøjer m.v.
Xxxxxxxxxxx og personlig konfiguration skal tage afsæt i målet om at optimere og lette brugernes daglige arbejdsgange i Løsningen, som kan variere afhængig af brugerprofilen.
4.13.1Processer for brugerhjælp og personlig konfiguration
Brugerne kan få behov for brugerhjælp i alle dele af arbejdet i Løsningen, men brugerhjælp er særlig relevant de steder, hvor brugeren skal foretage handlinger eller indrapportere data. Det er et væsentligt princip, at brugerhjælpen er tilstede det sted i brugergrænsefladen, hvor brugeren skal anvende hjælpen.
Personlig konfiguration vil typisk ske som led i den indledende opsætning, når en bruger er blevet tildelt adgang. Konfiguration vil derudover ske løbende, i takt med at brugeren bliver bedre bekendt med konfigurationsmulighederne og som led i brugerens løbende til- og fravalg af faste søgninger, favoritdokumenter m.v.
Epic 51 – Personlige konfigurationer
Epic |
Nr.: |
51 |
|
Str.: |
L |
Tema: |
Brugerhjælp og personlig konfiguration |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne lave personlige konfigurationer af brugergrænsefladen, så jeg f.eks. kun ser relevante kolonner i listevisninger m.v., kan gemme faste søgninger eller filtre, og udpege favoritdokumenter. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne gemme faste søgninger. Brugeren skal kunne gemme sorteringen af filtre i søgeresultater og andre listevisninger. Xxxxxxxx skal kunne administrere, hvilke kolonner der vises i søgeresultater og andre listevisninger. Xxxxxxxx skal kunne favoritmarkere dokumenter, som derefter kan fremfindes, uden at der skal foretages en dokumentsøgning. Brugeren skal kunne angive standart filplaceringer for import og eksport af dokumenter. |
|||||
Bemærkninger / Afklaringer |
|||||
Personlige konfigurationer er kun muligt i begrænset omfang i den nuværende Lex Dania klient. |
|||||
Epic 52 – Visning af e-læringsmodul
Epic |
Nr.: |
52 |
|
Str.: |
L |
Tema: |
Brugerhjælp og personlig konfiguration |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne tilgå et e-læringsmodul integreret i den moderniserede Lex Dania klient, så jeg kan blive guidet igennem funktionalitet og dokumentflows i brugergrænsefladen. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne åbne og gennemføre e-læringsmodulet fra den moderniserede Lex Dania klient. |
|||||
Bemærkninger / Afklaringer |
|||||
Kunden ønsker, i samarbejde med Leverandøren, at afdække mulighederne for integration af relevante e-læringsværktøjer til løbende brugeruddannelse dels i grundlæggende funktionalitet, dels til brug ved introduktion af ny funktionalitet. |
|||||
Epic 53 – Instruktionslag
Epic |
Nr.: |
53 |
|
Str.: |
M |
Tema: |
Brugerhjælp og personlig konfiguration |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne få vist et instruktionslag i brugergrænsefladen, så jeg kan få highlightet kernefunktioner og blive instrueret i forbindelse med ny ukendt funktionalitet. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne få vist ”Instructional Overlay”, ”Coach Marks”, eller lignende direkte i brugergrænsefladen. Xxxxxxxx skal kunne vælge ikke at blive præsenteret med instruktionerne igen. |
|||||
Bemærkninger / Afklaringer |
|||||
Ingen bemærkninger. |
|||||
Epic 54 – Hjælpetekst
Epic |
Nr.: |
54 |
|
Str.: |
M |
Tema: |
Brugerhjælp og personlig konfiguration |
||||
Beskrivelse |
|||||
Som bruger vil jeg kunne læse hjælpetekst ved inputfelter og handlinger, så jeg kan få specifik og handlingsanvisende hjælp i dokumentbearbejdningen. |
|||||
Acceptkriterier |
|||||
Brugeren skal kunne få vist hjælpetekster til brugergrænsefladen ved at trykke på et interaktivt element. |
|||||
Bemærkninger / Afklaringer |
|||||
Hjælpetekster vil som udgangspunkt skulle skrives og holdes ajour af Kunden. Det er derfor vigtigt, at Kunden kan aktivere/deaktivere og redigere i hjælpetekster, uden det forudsætter release eller anden indblanding fra Leverandøren. |
|||||
5Ikke-funktionelle krav
Dette kapitel indeholder de ikke-funktionelle krav til den moderniserede Lex Dania klients arkitektur og design, dvs. krav til Leverancens egenskaber og kvalitet, som har til hensigt at understøtte de funktionelle krav i kapitel 3.
De ikke-funktionelle arkitektur- og designkrav til den moderniserede Lex Dania klient er således opdelt i følgende områder:
Målarkitektur.
Snitflader.
Brugerrettighedsstyring.
Den moderniserede Lex Dania klients brugergrænseflader.
I afsnittet indgår en række krav, hvor Leverandøren bedes forholde sig til målarkitekturen, samt øvrige krav. Målarkitektur
Dette afsnit beskriver Civilstyrelsens målarkitektur for Xxx Xxxxx produktion. Målarkitekturen har til hensigt at beskrive målet med Leverancen og være et pejlemærke for den ønskede udvikling og etablering af den moderniserede Lex Dania klient. Her bliver der taget udgangspunkt i de lov- og forretningsmæssige krav, som Kunden har til Leverancen. De kommende underafsnit tager udgangspunkt i arkitekturvisionen for hele Lex Dania produktion, hvor der i sidste underafsnit er beskrevet, hvad Leverancen indebærer. Målarkitekturen er beskrevet med afsæt i hele Lex Dania produktion for at give Leverandøren og Kunden et overordnet billede af det samlede arkitekturmål. Det er dog kun snitflader, der ligger tæt på Lex Dania klient, der er beskrevet detaljeret.
5.1.1Arkitekturvisionen
Det er Kundens ønske, at Lex Dania klient løftes ud af den nuværende ramme, som beskrevet i Figur 5 - Arkitekturtegning, således at de forskellige komponenter, der tilsammen udgør Lex Dania klient, bygges på en moderne og dokumenteret platform. Herved sikres, at Kunden i fremtiden har et moderne og driftssikkert værktøj, til at styre workflowet og arbejdsgangene i forbindelse med produktionen og publikationen af Folketingets dokumenter og centralt udstedte statslige forskrifter, samt opbygning og vedligeholdelse af relationer mellem de forskellige komponenter.
Kunden ønsker, at workflows og arbejdsgange i den moderniserede Lex Dania klient bygger på behov og feedback fra de daglige brugere på baggrund af workshops og test afholdt under udviklingsprocessen.
Xxxxxx har forsøgt at illustrere hvor grænsen går for Løsningen omfattet af nærværende bilag, i den fremhævede del af Figur 5 - Arkitekturtegning.
Figur 5 - Arkitekturtegning
5.1.2Komponenter og Snitflader
Der findes en række komponenter i den nuværende Lex Dania produktion. De fleste komponenter er tætkoblede. Et af målene i målarkitekturen i at fraskille snitfladerne og gøre dem uafhængige af hinanden. Herunder er de forskellige snitflader beskrevet hvor der er taget udgangspunkt i Målarkitekturen.
Id |
Komponent |
Beskrivelse |
1 |
Lex Dania klient |
En tynd klient, der bruges af Informationsleverandører til bearbejdning og publicering/kundgørelse af dokumenter. |
2 |
Lex Dania forretningslogik |
Et interface, der udstiller forretningsregler til alt forretningslogik, der findes i Lex Dania. |
3 |
Lex Dania server |
Komponent, der udstiller et interface, til skrive- og læseadgange til backend databasen. Lex Dania server indeholder desuden brugeradministration. |
4 |
FT Service |
En service, der står for at håndtere dokumenter fra Folketingets ind- og udbakke. |
5 |
Lex Dania job afvikler |
En hangfire service, der afvikler jobs og rapporterer fejl. |
6 |
Lex Dania logs |
En komponent, der holder alle logs, indeksering og visualisering. |
7 |
Xxx Xxxxx editor Eunomia |
Dokumentredigeringsprogram. |
8 |
Slutbrugersystemet |
De hjemmesider, der udstilles til slutbrugerne. Herunder en søgeindekseringsservice, database og fileshare. |
Tabel 6 - Snitflader i Xxx Xxxxx produktion
5.1.3Elementer
De forskellige komponenter er bygget op af flere elementer. De elementer er beskrevet her. Elementerne er igen mere detaljeret beskrevet jo tættere på Lex Dania klient, snitfladen er. Elementerne er skrevet i henhold til målarkitekturen.
Nedenstående elementer er yderligere uddybet i Bilag 03 (Beskrivelse af Kundens nuværende system – Xxx Xxxxx produktion og Statstidende).
5.1.3.1Xxx Xxxxx klient
En tynd klient, der bruges som brugergrænseflade til de professionelle bruger. Den tynde klient er bygget af tre lag. De tre lag/elementer er.
Præsentationslag
Logisk lag
Data adgangslag, der integrerer med Lex Dania forretningslogik snitfladen
5.1.3.2Xxx Xxxxx forretningslogik
En modul, der taler med Lex Dania server interfacet og udstiller eget interface med forretningsregler til forretningslogikken i Lex Dania produktion. Snitfladen består af tre elementer.
Et element, der udstiller et interface til de forskellige metoder.
Et element, der står for forretningslogikken.
Et element, der integrerer med Lex Dania serveren.
5.1.3.3Lex Dania server
En snitflade bestående af et interface, der udstiller de relevante skrive- og læseadgange til den tilhørende database. Snitfladen har to elementer.
Et element, der udstiller et interface til de relevante forretningsregler.
Et element, der kommunikerer med databasen.
Brugerstyring.
5.1.3.4FT Service (Lex Dania Folketing Service)
Folketingets service (Lex Dania Folketing Service), er en service der overvåger indbakken/udbakken, som benyttes til at integrere med Folketinget. Servicen overvåger den filmappe, hvor Folketingets service automatisk kan tilføje og hente filer fra. Servicen har to elementer.
Et element, der læser og skriver filer til filmappen.
Et element, der bearbejder filerne.
Yderligere information om denne service kan findes i Bilag 03 Beskrivelse af Kundens nuværende system) appendiks 03.13.
5.1.3.5Xxx Xxxxx job afvikler
Snitfladen står for at afvikle de forskellige jobkørsler, der er i komponenten og fejlrapportere ved eventuelle fejl. Snitfladen består af flere elementer.
Et element, der udstiller et interface til styring af jobkørsler samt læsning af job status og fejl.
Et element, der styrer jobkørslerne.
En database, der holder styr på de forskellige kørsler og fejl.
Flere elementer, der hver især er ansvarlig for et job. (Der er i Bilag 03a (Teknisk beskrivelse af Xxx Xxxxx klient) beskrevet de eksisterende 16 forskellige job).
5.1.3.6Xxx Xxxxx logs
Lex Dania logs består af flere elementer, der håndterer, visualiser og sortere de forskellige logs, der bliver skrevet i Xxx Xxxxx produktion.
Et element, der udstiller et interface med metoder til skrivning og læsning af logs.
En database, der holder alle logs.
Et element, der indekserer logs.
Et konfigurerbart dashboard, der visualiserer alle logs.
5.1.3.7Xxx Xxxxx editor Xxxxxxx
Eunomia er et redigeringsprogram, der bliver brugt til at udarbejde de forskellige dokumenttyper. Her er elementerne ikke beskrevet, da det ikke har en direkte integration til Lex Dania klient.
5.1.3.8Slutbrugersystemet
Slutbrugersystemet er det system, der udstiller frontend hjemmesiderne, herunder xxxxxxxxxxxxxxx.xx og xxxxxxxxxx.xx. Slutbrugersystemets elementer er ikke beskrevet, da de også ligger langt fra Lex Dania klient og ikke har nogen direkte relation.
5.1.4Integrationer
Der findes ikke nogen udefrakommende integrationer i Lex Dania produktion.
5.1.5Mål og principper
Målet med arkitekturen er at gøre det nemmere at vedligeholde, udskifte og drifte de forskellige komponenter og elementer. Nedenfor er listet de overordnede mål og principper til opnåelse af den ønskede arkitektur.
Kommunikationen mellem systemer skal foregå med de mest moderne, populære og veldokumenterede specifikationer som f.eks. OpenAPI, REST eller gRPC. Leverandøren skal hvor muligt anvende de til en hver tid gældende fællesoffentlige retningslinjer for formidling og dokumentation af arkitektur i digitaliseringsprojekter jf. Bilag 05 (Dokumentation).
Der skal være en løs kobling mellem komponenter og elementer, således at ikke berørte komponenter og elementer ikke påvirkes ved ændringer.
Grundig dokumentation af hvert element, for at gøre eventuelle fremtidigeudviklingsopgaver nemmere jf. Bilag 05 (Dokumentation).
|
|
Kravtype |
M |
|
Overskrift |
Systemuafhængig brugerrettighedsstyring |
||
Kundens krav |
Leverandøren skal sikre, at brugerrettighedsstyring sker uafhængigt af andre systemer og løsninger, herunder databaser. Brugerrettighedsstyringen skal være i stand til at fungere selvstændigt og ikke kræve integration med specifikke platforme eller offentlige infrastrukturkomponenter. |
||
|
|
Kravtype |
M |
|
Overskrift |
Logning i Løsningen |
||
Kundens krav |
Leverandøren skal implementere logning i Løsningen, således at der er sporbarhed på alle væsentlige handlinger jf. Bilag 08 (Sikkerhed). |
||
|
|
Kravtype |
M |
|
Overskrift |
Principle of Least Privilege |
||
Kundens krav |
Løsningen skal designes efter “Principle of Least Privilege“, hvilket betyder, at aktører og Brugere samt komponenter, processer og programmer alene kan tildeles det minimum sæt af rettigheder, som er nok til, at Aktøren kan udføre sin specificerede opgave. |
||
5.2Krav til realisering af målarkitekturen
Med udgangspunkt i den af Kunden opstillede målarkitektur, samt de funktionelle og øvrige ikke-funktionelle krav, skal Leverandøren definere en konkret løsningsarkitektur. Nedenfor følger en række krav til realiseringen af løsningsarkitekturen.
Leverancen ligger op til en agil arbejdsgang mellem kunden og leverandøren. Hele arbejdsgangen er beskrevet i Bilag 10b (Udviklingsmetode).
|
|
Kravtype |
M |
|
Overskrift |
|
||
Kundens krav |
Løsningen skal kunne distribueres til, anvendes uden behov for administratorrettigheder. Dette indebærer, at Brugerne skal kunne afvikle Løsningen uden assistance fra administratorer eller superbrugere. |
||
5.2.1Standardprogrammel og Kundespecifikt Programmel
Kunden har ikke lagt sig fast på, hvorvidt Løsningen skal udgøres af standard- eller specialudviklet software. Kunden forventer overordnet set, at Leverandøren anvender Standardprogrammel til løsning af almindelige udbredte funktionalitet og Kundespecifikt Programmel til opgaver, som er specifikke for Kunden. Med andre ord ønsker Xxxxxx, at Leverandøren udnytter Standardprogrammel til det, det er bedst til, men ikke til alle opgaver for enhver pris. Er Standardprogrammel belagt med licensbetaling godkender Kunden om Standardprogrammellet kan anvendes.
Leverandøren skal overholde Kundens krav til brug af Standardprogrammel og Leverandørspecifikt Programmel, jf. Bilag 10b (Udviklingsmetode).
5.3Implementering af Løsningen
Løsningen skal under Implementering understøtte parallel drift med fælles datagrundlag via teknisk synkronisering. Dette indebærer, at Brugerne skal kunne afvikle og bearbejde dokumenter i den nuværende Lex Dania klient, der skal udfases i en overgangsperiode jf. Krav 7b.5. Det skal aftales nærmere med Kunden, jf. Bilag 10 (Samarbejdsorganisation) samt i forlængelse af Krav 7b.5.
Kunden forventer at Overgang til Moderniseret Xxx Xxxxx Xxxxxx tager op til 12 måneder.
|
|
Kravtype |
EK |
|
Overskrift |
Overgang til ny Lex Xxxxx Xxxxxx |
||
Kundens krav |
Leverandøren skal have en strategi for udrulning af Løsningen, herunder data- og brugermigrering, uddannelse af Brugere mv. Strategien skal bl.a. indeholde: Leverandørens tilgang til opdeling af udrulningen. Risikovurderings- og kontrolprocedurer. Inddragelse af Informationsleverandører og andre Brugere samt brugerstyring i overgangen. Procedurer for opretholdelse af dataintegritet. Procedurer for overholdelse af krav til drift, herunder servicemål. Plan for nedlukning af, og oprydning efter, den eksisterende Lex Dania klient under overholdelse af Krav 7b.7. Strategiens overholdelse af den Agile Metode. |
||
|
[Tilbudsgiverne skal indsætte en beskrivelse af deres strategi for udrulning af Løsningen. Beskrivelsen bør omfatte:
Tilbudsgiver kan vælge at vedlægge sin beskrivelse som underbilag til nærværende bilag nummeret som Underbilag 07b [1,2 ...]. Henvisninger til sådanne underbilag indsættes i denne celle af kravboksen. Positive momenter ved evalueringen: Det vægter positivt ved evalueringen,
] |
||
|
|
||
|
|
Kravtype |
M |
|
Overskrift |
Standardisering af programmel |
||
Kundens krav |
Leverandøren skal sørge for, at den ændrede kode lever op til fællesoffentlige arkitekturstandarder og best practices, når det kommer til kodens struktur, navngivning, test og sikkerhed. |
||
|
|
Kravtype |
M |
|
Overskrift |
Oprydning af programmel |
||
Kundens krav |
Hvis eksisterende funktionalitet bliver udfaset i øvrige komponenter, skal Leverandøren også rense for gammel ubrugt kode, der har været en del af det udfasede projekt. Kode der ikke er brugt i Løsningen og øvrige komponenter skal også fjernes for at højne vedligeholdelsesniveauet. |
||
5.4Løsningens brugergrænseflade
I dette afsnit beskrives krav til den moderniserede Lex Dania klients brugergrænseflader, herunder bl.a. krav til brugervenlighed og tilgængelighed. Den moderniserede Xxx Xxxxx xxxxx skal i videst mulig opfang leve op til kravene i Det Fællesoffentlige Design System. Se evt. xxxxx://xxxxxxxxxxxx.xx/.
Med brugergrænseflader menes her de eller den af Leverandøren udviklede brugergrænseflader, der erstatter den eksisterende brugergrænseflade i den nuværende Lex Dania klient.
5.4.1Lex Dania klient brugergrænseflade
Et af de primære fokusområder for designet af den moderniserede Lex Dania klient, dvs. brugergrænsefladen for alle Brugere, er at systemunderstøtte Brugernes arbejdsgange og sikkerheden i disse. Her tænkes blandt andet på implementering af opgaveorienterede workflows, så påkrævede kontroller foregår i og styres af selve den moderniserede Lex Dania klient, i stedet for at foregå udenfor og afkoblet fra den moderniserede Lex Dania klient, hvor den enkelte Bruger selv må implementere procedurer eller henholde sig til brugervejledninger herfor.
5.4.1.1Brugervenlighed og tilgængelighed
Brugervenlighed skal sikre, at den moderniserede Lex Dania klient er bekvem at betjene, og at klienten reagerer og fungerer, som en Bruger vil forvente. Tilgængelighed skal sikre, at alle Brugere uanset handicap eller funktionsnedsættelse kan benytte den moderniserede Lex Dania klient.
Den moderniserede Lex Dania klients sider skal have ensartet design, så Løsningen fremstår som homogen for Brugerne. Information og betjening af brugergrænsefladen skal være forståelig og præsenteres i en meningsfuld rækkefølge, herunder at der er konsistens i præsentationen af siderne og funktionerne. Eksempelvis skal tabulatorrækkefølgen af knapper og inddateringsfelter være logisk i forhold til Brugerens arbejdsgang. Yderligere design og betjening af brugergrænsefladen afklares og testes i udviklingsfasen med og af Kunden og Kundens interessenter jf. Bilag 10b (Udviklingsmetode) for at sikre en optimal brugeranvendelse af den Moderniserede Lex Dania-klient, samt i henhold til Leverandørens strategi for overgang til Løsningen, jf. Krav 7b.5.
|
|
Kravtype |
M |
|
Overskrift |
Tastatur og genvejstaster |
||
Kundens krav |
Alle hyppigt anvendte funktioner til sagsbehandling skal også kunne betjenes via en tastaturgrænseflade. Derudover skal der være genvejstaster til relevante funktioner. |
||
Selvom den moderniserede Lex Dania klient ikke er omfattet af webtilgængelighedsloven (Lov om tilgængelighed af offentlige organers websteder og mobilapplikationer (Lov nr. 692 af 08/06/2018)), ønsker Kunden af Løsningen lever op til WCAG 2.1 niveau AA.
Hvis der er WCAG 2.1 niveau AA krav, som ikke opfyldes i Løsningen, skal disse tydeliggøres i en erklæring svarende til den tilgængelighedserklæring, som udarbejdes for it-løsninger, som er omfattet af webtilgængelighedslovens § 4, stk. 1.
Erklæringen udarbejdes af Leverandøren og godkendes af Kunden inden Overtagelsesprøven.
Tilgængelighedskrav i WCAG 2.1 niveau AA kan fraviges ved Kundens skriftlige godkendelse.
5.4.1.2Brugercentreret designproces for Xxx Xxxxx-klienten
Leverandøren skal i forbindelse med design og udformning af den moderniserede Lex Dania klient anvende brugercentrerede designprincipper (UX design) i udviklingsfasen.
Leverandøren skal som en del af udviklingen aktivt faciliterer workshops med Kunden og Brugere af Lex Dania klient vedrørende design og evaluering af den moderniserede Lex Dania klient, og at Leverandøren anvender velafprøvede og anerkendte metoder inden for brugercentreret design.
|
|
Kravtype |
M |
|
Overskrift |
Brugercentreret designproces |
||
Kundens krav |
Der skal under udviklingen af den moderniserede Lex Dania klient faciliteres workshops af Leverandøren, hvor Kunden og Brugere af Lex Dania klient deltager. De faciliterede workshops skal teste og evaluere de forskellige brugerrejser med funktionelle prototyper, med henblik på at tilpasse brugerfladen efter behov. |
||
5.4.1.3Vejledning
Den moderniserede Lex Dania klient skal indeholde klart forståelige vejledninger og meddelelser, som hjælper Xxxxxxxx til at udføre deres opgaver, korrigere fejl, og som ikke forstyrrer mere end højst nødvendigt.
|
|
Kravtype |
M |
|
Overskrift |
Hjælpetekster og vejledninger |
||
Kundens krav |
Der skal i den moderniserede Lex Dania klient kunne vises relevante hjælpetekster på de enkelte skærmbilleder, ligesom der som en del af teksten skal kunne indsættes link til udførlige vejledninger, som er let tilgængelige, f.eks. til en hjælpeside i den moderniserede Lex Dania klient eller som link til relevant sted. Leverandøren skal udarbejde udkast til hjælpetekster og vejledninger. Kundens administrator skal godkende og senere have mulighed for at vedligeholde hjælpeteksterne og vejledningerne. |
||
|
|
Kravtype |
M |
|
Overskrift |
Felthjælpetekster, -fejlmeddelelser og -vejledninger |
||
Kundens krav |
Der skal i den moderniserede Lex Dania klient kunne vises relevante fejlmeddelelser og hjælpetekster samt vejledninger på de enkelte indtastningsfelter. Leverandøren skal udarbejde udkast til felthjælpetekster og feltfejlmeddelelser samt feltvejledninger. Kundens administrator skal godkende og senere have mulighed for at vedligeholde felthjælpetekster og feltfejlmeddelelser samt feltvejledninger. |
||
|
|
Kravtype |
M |
|
Overskrift |
Xxxxxxxxxx af felter og bekræftelse af handling |
||
Kundens krav |
Den moderniserede Lex Dania klient skal indeholde validering af inputdata i datafelter samt kræve bekræftelse af Brugeren ved relevante handlinger, f.eks. ved sletning af data. Brugeren skal tydeligt orienteres gennem entydig og løbende feedback. Dette gælder for såvel interaktion med brugergrænsefladens knapper, inputbokse, flows, fejlbeskeder og respons ved ventetid. |
||
|
|
Kravtype |
M |
|
Overskrift |
Rettidig og brugbar feedback |
||
Kundens krav |
Hvis en handling, f.eks. ved søgning efter data, betyder, at Løsningen skal arbejde længere end fastsatte Servicemål, jf. Bilag 06 (Servicemål), skal Xxxxxxxx informeres om at ”systemet arbejder”. Dette gælder også som følge af langsom eller manglende internetforbindelse. |
||
5.4.1.4Tekniske krav til brugergrænsefladen i den moderniserede Lex Dania klient
Brugergrænsefladen skal gennem teknisk understøttelse bidrage til at optimere Brugernes arbejdsgange.
|
|
Kravtype |
M |
|
Overskrift |
Tilpasning af brugergrænseflade |
||
Kundens krav |
Den moderniserede Lex Dania klient skal kunne anvendes på tværs af forskellige typer af enheder og skal derfor bygges efter princippet om ”Responsive Design”, således at brugergrænsefladen tilpasser sig den skærmopløsning og enhed, der logges på fra. Kunden skal i tilfælde af konflikt, prioritere hvilke typer enheder hvorpå Løsningen skal kunne anvendes. |
||
|
|
Kravtype |
M |
|
Overskrift |
Xxxxxxxxxx af flere skærme |
||
Kundens krav |
Den modernisere Lex Dania klient skal kunne udnytte tilkoblingen af flere skærme til en arbejdsplads, så Brugeren får overskuelig adgang til information. F.eks. således at en Bruger kan betjene flere skærmbilleder i den moderniserede Lex Dania klient på en overskuelig måde fordelt over flere skærme. |
||
|
|
Kravtype |
M |
|
Overskrift |
Skalerbare skærmbilleder |
||
Kundens krav |
Skærmbillederne skal være fleksibelt skalerbare til forskellige skærmopløsninger , så pladsen på skærmen udnyttes optimalt uden unødig scrolling og uden unødig uudnyttet plads. |
||
|
|
Kravtype |
M |
|
Overskrift |
Browserunderstøttelse |
||
Kundens krav |
Såfremt Løsningen er browserbaseret, skal den moderniserede Lex Dania klient som minimum kunne anvendes i supporterede versioner af følgende browsere Microsoft Edge for Business og Google Chrome. Såfremt der sker ændringer i de browsere, der stilles til rådighed på Statens It-arbejdsplads, vil dette kunne håndteres som en Ændring, jf. Bilag 09 (Ændringshåndtering af Kontraktuelle Ændringer). |
||
1 Læs mere på xxxxx://xxx.xxxxxxxxxxxxxxx.xx/xxx
Side 1 af 52 |