Metodehåndbog. Use Cases KOMBIT
|
|
- Sidsel Danielsen
- 8 år siden
- Visninger:
Transkript
1 Metodehåndbog Use Cases KOMBIT 1
2 Indhold Metodebog for use cases... 3 Baggrund... 3 Use case Find aktører Find use cases Beskriv use cases... 9 Hvornår er use case-modellen færdig? Hvor lang tid tager det at udarbejde en use case? Kvalitetskriterier Use cases i Qualiware Bilag: Use cases i KOMBITs projekter Use cases fra Beskedfordeler projektet: Beskedfordeling Modtag besked fra Afsendersystem (UC-2B-01) Distribuer besked (UC-2B-02) Aflever besked (UC-2B-03) Afhent besked (UC-2B-04) Use cases fra Sygedagpengeprojektet: Opret sag Opret sygefraværssag automatisk (UC-60) Opret sygefraværssag manuelt (UC-01)
3 Metodebog for use cases Denne metodebog er udarbejdet for at skabe en ens metode for brugen af use cases i KOMBIT. Ens metoder vil både fremme genbrug af eksisterende use cases samtidige med, at det vil sikre en ensartet kommunikation med eksterne Leverandører af Løsninger til Kommunerne. Use cases benyttes til at beskrive den fremtidige Løsnings funktionalitet. Use case i KOMBIT er forretnings use cases og dermed det forretningsmæssige grundlag for it-systemets funktionalitet. KOMBIT udarbejder use cases og it-leverandøren udarbejder system use cases og eventuelt user stories. Hierarkiet i modellerne ses i Informationssøjlen på figuren nedenfor. Figur 1: OIO reol med fokus på Use cases.(rød farve indikerer, at det er Leverandørens område.) Digitaliseringsstyrelsen anbefaler også brugen af Use cases, som indgår i deres oplæg til OIO-reolen 1. Som aktivitet ligger Use Cases under Forretning, men Digitaliseringsstyrelsen har valgt, at som dokumentation er Use Cases lagt under Applikation, da det er dér, man får overblik over brugere og deres interaktion med et system. Det omfatter ligeledes andre systemer, så dermed er det dér, man får overblik over funktionelle behov/krav og integrationsbehov/krav. Det er altså mere applikationsnært end den rene forretningskortlægning og modellering, som jo i princippet kan fungere helt uden et system. Vi har beholdt Use cases under Forretning, idet vi beskriver aktiviteterne i vores OIO reol. Baggrund En use case er en enkel og struktureret fortælling om, hvordan mennesker eller systemer bruger et system til at løse en opgave. Den beskriver, hvad omverdenen forventer af et system og adskiller sig herved fra forretningsprocesserne, som beskriver sekvenser af enkeltaktiviteter, der udføres for at opnå et forretningsmæssigt mål
4 Den semiformelle struktur har den fordel, at slutbrugere nemmere forstår en kravspecifikation uden at være specielt trænet heri. En anden fordel er, at den hjælper til at forstå, hvad systemet skal indeholde, mens kravene stadig befinder sig på skrivebordet. Herved sikres, at ikke kun it-eksperter, men også enhver anden interessent kan danne sig et billede af den ønskede funktionalitet. Den strukturerede tilgang har endvidere den fordel, at det er nemmere at sammenligne formuleringer og derved kan undgå, at fortællingerne kommer i modstrid med hinanden. En konsekvent gennemgående struktur understøtter derudover arbejdet med at sikre fuldstændige krav og er med til at forhindre redundante eller manglende krav. Use cases sætter anvendelsesdetaljer i den rette kontekst og bidrager derved til at forhindre flertydighed i kravene. Use cases er udgangspunktet for udvikling af systemer og tjener derfor som indledende programmeringsgrundlag. De kan være udformet på forskellige detaljeringsniveauer, men udgangspunktet er altid det forretningsmæssige behov, som kan nedbrydes til større og større detaljeringsgrad i takt med, at kravene overgår til design og udvikling. I KOMBIT beskriver vi udelukkende use cases på forretningsniveau. Til gengæld beder vi leverandøren om i designfasen at beskrive use casen i større detaljeringsgrad og med frekvenser (system use cases), således at det er muligt at udarbejde mere detaljerede test cases på baggrund af disse. Alle system use cases skal godkendes af KOMBIT. En god use case kan herudover danne grundlaget for en eller flere testcases i accepttesten. Use cases dækker de funktionelle krav til et system, men ikke de non-funktionelle. Der skal stadigvæk sættes krav til systemegenskaber som for eksempel skalerbarhed, sikkerhed, performance mf. Gode grunde til at bruge use cases 2 : Use cases er motor i udledningen af funktionelle krav. Use cases danner basis for definitionen af de funktionelle krav. Use cases understøtter systemafgrænsning. Use cases støtter kommunikationen med slutbrugere og kunder. Use cases giver den dynamiske black-box synsvinkel på et kommende eller eksisterende system. Use cases er grundlag for udledning af objekter. Use cases understøtter kravsporingsarbejdet. Use cases er basis for brugergrænseflade og indledende design. Use cases understøtter mapningen fra funktionelle krav til objekt- og komponentstrukturer. Use cases definerer adgangsmønstre til en database. Use cases støtter dimensionering af processorkapacitet. Use cases udgør basis for integrationstest. Use cases definerer test cases. Use cases udgør basis for incrementel systemudvikling. Use cases hjælper til at estimere projekters omfang. Use cases er udgangspunkt for brugerdokumentation og manualer. 2 Kilde: Ivar Jacobson: Forord i Armour + Miller Advanced use case modelling, Addison Wesley
5 Use cases kan bruges som projektstyringsværktøj. Use cases kan i reenginering aktiviteter anvendes til at beskrive, hvad et legacy system gør. Use case Use cases indgår i en use case model, som indeholder: o en liste over aktører o use case diagram(mer) (som er den grafiske fremstilling, der visualiserer grænsen mellem system og omverden i forholdet mellem aktører og enkelte use cases, samt mellem use casene indbyrdes) o tekstuelle beskrivelser ( fortællinger ) o eventuelt use case-grupperinger (pakker) Use case modellen udarbejdes i tre trin 1. Find aktører 2. Find use cases 3. Beskriv use cases 1 Find aktører Use cases igangsættes af aktører og en del af arbejdet med use cases udgøres derfor af aktør-identifikation og aktørbeskrivelser. Aktører er personer eller systemer, der vil anvende systemet og som har et eller flere forretningsmæssige mål, der skal opfyldes af en eller flere use cases. I kommunal sammenhæng vil en typisk aktør ofte være en sagsbehandler og et typisk it-system vil for eksempel være CPR fra Serviceplatformen. I første omgang kan man udlede de overordnede aktører fra de interessenter, der er beskrevet i projektets idéfase. Det er muligt, at interessentanalysen ikke har medtaget systemer men kun personer. I dette tilfælde vil systemaktørerne blive identificeret i en senere forfining af aktøranalysen. Aktører kan have forskellig interesse i use casene og karakteriseres derfor som primær, henholdsvis sekundær aktør. o o Primær aktør er altid den aktør, der igangsætter use casen, og for hvem use casens opfyldelse giver forretningsmæssig værdi. I en kommune kan det for eksempel være sagsbehandleren. Sekundær aktør er en nødvendig deltager for at opfylde den primære aktørs mål. Et eksempel på en sekundær aktør kan være CPR, som leverer data til bekræftelse af en ansøgers identitet. Det kan i nogle tilfælde være vanskeligt at vurdere, hvem der igangsætter en use case specielt i de tilfælde, hvor det er en systemaktør. I de tilfælde er det en god idé at bruge Processerne til at hjælpe med identifikationen. Når aktørerne er identificeret udarbejdes et kontekstdiagram. Kontekstdiagrammet indeholder alle aktørerne og de er beskrevet som henholdsvis bruger- og systemaktører. 5
6 Beskedfordeler Serviceplatform Security Token Service Administrationsmodul Støttesystem Klassifikation Afsendersystem Modtagersystem Klassifikationssystem Administrator Eksempel på kontekstdiagram (ikke Qualiware) Redaktør Tilslutningspart 2 Find use cases Aktøridentifikation indebærer naturligt, at man tænker i brugssituationer. På dette tidspunkt vil man identificere de første use cases, som vil blive suppleret i takt med at analysen afslører flere brugssituationer. Resultatet heraf vil i første omgang være en simpel liste over use cases. Et andet resultat af use case identifikationen vil være et use case diagram. At visualisere use cases i diagrammer er til stor hjælp, når man samarbejder med interessenter og domæneeksperter om at finde de ønskede og nødvendige use cases. Ligesom det er med til at synliggøre projektets status i kravfindingsprocessen for de funktionelle krav. I den endelige kravspecifikation vil use case diagrammet give et godt overblik over omfanget af den ønskede funktionalitet for leverandører og udviklere. Use case diagrammer følger UML-standarden. Det afbilder forholdet mellem et systems omgivelser (aktører) og dets funktioner (use cases). Det kan derudover illustrere afhængigheder mellem de enkelte use cases. Oversigt over symboler i et use case diagram: 6
7 Systemet Et system viser grænserne mellem løsningen og omverdenen. Pakke En pakke er en logisk samling af use cases, som naturligt hører sammen. Dvs. høj samhørighed inden for pakken. Brugeraktør En brugeraktør er en aktør, som er en person, der skal anvende løsningens brugergrænseflade. Et eksempel kan være en kommunal sagsbehandler. Systemaktør En systemaktør er et andet it-system, som har snitflader til løsningen. Et eksempel kan være en snitflade til CPR. 7
8 Use case En use case er en enkel og struktureret fortælling om, hvordan mennesker eller systemer bruger et system til at løse en opgave. Et eksempel på en use case kan være Opret sag. Association mellem aktør og use case Viser forbindelsen mellem aktøren og use casen. Eksempel: Sagsbehandler igangsætter Opret sag Include-relation mellem to use cases Angivelse af, at en use case kan omfatte gennemførelsen af en anden use case. Eksempel: use casen Opdater sag forudsætter at use case Find sag er gennemført. Extend-relation mellem to use cases Angivelse af at en use case er udvidet med en anden use case. Eksempel: use case Opret sag 8
9 er udvidet med en anden use case Tilknyt anmodning. Use case diagram Giver en oversigt over sammenhængen mellem aktør og use cases. 3 Beskriv use cases 1 Overordnet/kort beskrivelse Erfaringsmæssigt sker der forandringer i mængden og typer af use cases i løbet af krav og kontrakt fasen. I første omgang giver det derfor størst værdi for projektet kun at beskrive use cases kort og overordnet. Hertil er det tilstrækkeligt at anføre navn, aktør samt hvilken værdi funktionaliteten har for aktøren, sammen med basale administrationsoplysninger til at holde styr på udvikling og status. ID Navn Aktør Formål <unik <Aktivitet i bydemåde> <Aktørens navn> <Formål og værdi for aktøren> ID> Eksempel på kort beskrivelse: ID Navn Aktør Formål 9
10 67 Opret sag Sagsbehandler At oprette en sag for at kunne afgøre om en ansøger er berettiget til en ydelse. Basale oplysninger til brug for administration og opfølgning er: Kilde : De(n) person(er) eller det dokument der er ophavsmand. Forfatter : Personen som har formuleret use casen Status : Bearbejdningsstatus (f.eks. initiel, 1. gennemskrivning, reviewet, el.lign.) Versionsnr. : Dato : 2 Komplet beskrivelse Når man i projektet er nogenlunde sikker på at have de nødvendige use cases, beskrives hver enkelt use case mere detaljeret. Den mere indgående analyse, der følger af den detaljerede beskrivelse, kan give anledning til at use cases splittes op eller slås sammen, især når der skal tages stilling til alternativer til use casens normalforløb. Den færdige use case beskriver en komplet funktionalitet for systemet fra start til slut (obligatoriske oplysninger er markeret med *). Dette omfatter: *ID *Navn *Aktør *Formål *Igangsættende hændelse *Startbetingelser/forudsætninger *Normalforløb *Slutresultat Sluttilstand Alternativer til /Afvigelser fra normalforløbet Brugervendt nøgle Lovhenvisning Unik ID Aktivitet i bydemåde. Navn på den igangsættende aktør. Kort beskrivelse af det forretningsmæssige mål og eventuel afgrænsning til andre use cases. Den begivenhed eller hændelse, som udløser aktørens handlinger i normalforløbet. De forudsætninger, der skal være opfyldt for at normalforløbet kan gennemføres frem til slutresultatet. Forløb af handlinger, der uden afbrydelser fører fra den igangsættende hændelse til slutresultatet. En god tommelfingerregel er at holde antallet af handlinger mellem 3 og 9. Hvis antallet falder uden for dette interval, er der god grund til at overveje, om use casen er berettiget eller måske indeholder mere end én brugssituation. Det ønskede forretningsmæssige mål. Objekters ændrede tilstand (for eksempel kan sagstilstanden være ændret til oplyst ). Alternative forløb ved afbrudt normalforløb, som ender med en fejlsituation eller med en genoptagelse. (Alternativer er beskrevet nærmere i ALTERNATIVER.) I nogle kravspecifikationer kan der være behov for at have en brugervendt nøgle, men det anbefales, at alle henvisninger rettes mod den unikke identifikation for at minimere fejl i forhold til henvisninger. Er kun relevant i lovbaserede systemer og vil være udfyldt med lovtitel og relevante paragraffer, hvor det er hensigtsmæssigt. 10
11 I KOMBIT anvender vi en skabelon for usecase-beskrivelsen i standardkravspecifikationen: Use Case # <unik identifikation> Udfyldt af <bruges kun i skrivefasen og udelades i selve kontraktmaterialet> Formål, beskrivelse og afgrænsning Hændelse Forudsætninger Navn <handling i bydemåde ud fra aktørens synsvinkel> Baseret på følgende lovgivning <Henvisning til relevant lovgivning> Formål: Beskrivelse: Afgræsning: <Begivenheden der igangsætter/udløser use casen> <Nødvendige forudsætninger for at use casen kan gennemføres> Igangsættende aktør <den aktør der igangsætter use casen og har slutresultatet som forretningsmæssigt mål> Handlinger <Aktørens handlinger i det normalforløb (solskinsscenarie) der fører frem til slutresultatet. Handlingerne kan nummereres for at kunne placere undtagelser fra normalforløbet i forhold til handlingerne, men det er vigtigt at det ikke er trin der beskrives.> Slutresultat <Det forretningsmæssige resultat, som aktøren ønsker at opnå> Alternativer: <Afvigelser fra normalforløbet (undtagelser, varianter eller fejlsituationer). Et alternativ peger tilbage til handlingerne i normalforløbet ved hjælp af nummeret fra handlingen kombineret med et bogstav (fx 1a, 1b som alternativer til handling 1). Alternativer som ikke refererer til en bestemt handling kan markeres med *. (fx *a, *b)> Sluttilstand <Forretningsobjekter som har ændret status som resultat af use casen> Bemærkninger: <Eventuel relevant information, som ikke er direkte del af use casen> Eksempel på use case med udgangspunkt KSD-kravspecifikationen: UC-15 Navn: Opret sygefraværssag Baseret på Sygedagpengelovens 38. stk.4 Igangsættende aktør Sagsbehandler i ydelsescenter Formål, beskrivelse og afgrænsning En sygefraværssag oprettes manuelt af en sagsbehandler i ydelsescentret i de tilfælde, hvor en virksomhed ikke kan indberette sygefraværet via den virksomhedsvendte selvbetjeningsløsning (NemRefusion). Når sagen er oprettet, skal sagen være forsynet med alle obligatoriske sagsoplysninger, relevante personoplysninger, oplysninger om eventuelle tidligere ydelser, samt relevante metadata (KLE, kassation, m.v.). Herefter overgår den til automatisk sagsbehandling. Startbetingelser Sagsbehandleren er logget på Løsningen og har rettighede til at oprette en sygefraværssag. Løsningen indeholder ikke nogen eksisterende åben sygefraværsag på den sygemeldte, der skal oprettes en sag for. Der foreligger oplysninger, som muliggør oprettelse af sagen. Udløsende begivenhed En sygemeldt har henvendt sig til ydelsescenteret, fordi han er syg på 1. ledighedsdag, hvorfor hverken a-kassen eller nogen arbejdsgiver indberetter sygefraværet. Handlinger Sagsbehandleren: 1. indtaster de oplysninger, som den sygemeldte har afgivet. 2. tilknytter eventuelle tilhørende dokumenter 11
12 3. gemmer de indtastede oplysninger Løsningen: 4. tilføjer relevante metadata 5. henter information om andre relevante ydelser til sygemeldte fra Ydelsesindeks og knytter den til sagen Sagsbehandleren: 6. bekræfter oplysningerne Løsningen: 7. sender besked om at sygefraværssagen er oprettet til omkringliggende støttesystemer, herunder Sags- og dokumentindeks Slutresultat Der er oprettet en ny sygefraværssag, som indeholder de sagsdata, der er relevante for sagsbehandlingen, samt de evt. tilknyttede dokumenter. Sagen indeholder relevante metadata (KLE, kassation m.v.) Sygefraværssagen fremgår af en sagsoversigt i Løsningen Alternativer: 5a Ydelsesindeks meddeleler at oplysninger ikke kan hentes: Sagsbehandler bekræfter oplysningerne og opretter en påmindelse på sagen. Sluttilstand Bemærkninger: Sagen har sagstilstanden Oprettet Den tilgrundliggende proces er illustreret som P1 i Underbilag (Forretningsprocesser). Det kan i især i det indledende kravfindingsarbejde betale sig at arbejde med use casene i en matrix, som sidenhen overføres til Qualiware ved hjælp af importfaciliteten her. Alternativer Hovedbeskrivelsen for en use case er normalforløbet for, hvordan aktøren interagerer med systemet uden at tage højde for fejlsituationer eller eventuelle alternative forløb. Beskrivelsen af afvigelser fra normalforløbet udskilles i et særligt afsnit, er i skabelonen benævnt som Alternativer. Alternativer anføres ved at henvise til den handling, der er anført i normalforløbet ved at forsyne handlingsnummeret med et bogstav. To afvigelser til handling 1, vil herefter være kendetegnet 1a og 1b Afvigelser som ikke hænger sammen med en bestemt handling markeres med * og enkeltbogstaver, f.eks. *a. For hver afvigelse skrives desuden, hvad der skal ske ved afvigelsen. Dette skrives i punktform som i normalforløbet. Afvigelser bør kun omfatte situationer, som systemet har mulighed for at reagere på. En afvigelse, som systemet ikke skal reagere på, skal ikke beskrives. I forhold til fejl kan opgaven med at identificere alternativer/afvigelser ligge i kravspecificeringsfasen, i udviklingsfasen eller overlades til programmørens ad hoc beslutning. Ofte er der et omfattende udredningsarbejde forbundet med at udtænke mulige fejlsituationer, hvor det som regel ikke er oplagt for programmøren at vide, hvordan systemet skal reagere, hvis ikke alt går efter planen. Det er vigtigt at kravene til håndtering af afvigelser udarbejdes i fællesskab af leverandør og KOMBIT og det enkelte projekt skal afgøre, hvornår det vil være relevant at forfine use casene på dette punkt. Det skal afvejes, hvornår i projektets levetid denne tid skal investeres. Afvigelser kan være af følgende type: 12
13 Alternative veje til succes (eksempel: sagsbehandleren anvender en genvej, men ender ved samme slutresultat). Fejl ved aktørens handling (eksempel: sagsbehandleren taster ugyldigt cpr-nummer, retter fejlen og fortsætter normalforløbet til slutresultatet). Den igangsættende aktør foretager sig intet (eksempel: systemet får time-out og normalforløbet afbrydes). En sekundær aktør gør intet (eksempel: cpr-systemet svarer ikke på forespørgslen og sagsbehandleren afbryder normalforløbet). En sekundær aktør gør noget forkert (eksempel: systemet reagerer med en tilbagemelding og afbryder normalforløbet ) Som regel er det ikke nødvendigt at angive, hvad der skal ske efter at afvigelsen er håndteret, da det fremgår af sammenhængen, men hvis handlingerne afbrydes, bør man skrive det. Der kan opstå nye afvigelser, når man håndterer afvigelser. Som udgangspunkt indrykker man blot tilsvarende. Når man kommer langt ind i en sekvens af afvigelser, kan det blive så kompliceret at læse og forstå, at man må overveje at bide i det sure æble og splitte håndtering af afvigelserne ud i en separat use case. Husk at afvigelser kan være vigtige, så det kan give bagslag at springe dem over. Hvornår er use case-modellen færdig? Modellen er færdig når - Alle primære aktører og alle brugermål er behandlet. - Systemet kan reagere på alle de hændelser, det skal kunne reagere på. - Alle brugssituationer er beskrevet så klart, at: o Systemleverandør og -køber senere kan afgøre om "varen er levereret". o Brugerne kan acceptere systemet. Hvor lang tid tager det at udarbejde en use case? At udarbejde en use case kan være meget tidskrævende, men alternativet har vist sig at koste endnu mere tid -ikke blot i krav og kontraktfasen, men også i udviklingsfasen, hvorfor det også er en god idé at prioritere udarbejdelsen, så de vigtigste bliver lavet først. Tidsaspektet er også en af begrundelserne for, at stort set alle projekter i KOMBIT har valgt at bruge use cases. Kvalitetskriterier Overordnet gælder, at en use case o skal stå for sig selv - dvs. at den beskriver en samlet aktivitet; o har forretningsmæssig værdi for en aktør; o altid skal igangsættes af en aktør, som kan være en brugeraktør såvel som en systemaktør. Tjekliste Derudover skal det være muligt at svare JA til følgende spørgsmål: 1. Er afgrænsningen korrekt? Skal løsningen kun omfatte det, der ligger indenfor afgrænsningen? Skal alt indenfor afgrænsningen være understøttet af løsningen? 2. Udfører den igangsættende aktør handlinger? 13
14 3. Kan startbetingelserne kontrolleres? Kontrolleres de kun ved start af use casen? Skal de virkeligt være opfyldt? 4. Opfylder slutresultatet interessenternes interesser? 5. Starter normalforløbet fra den igangsættende hændelse og fortsætter indtil succes? 6. Har normalforløbet mellem 3 og 1handlinger? 7. Beskriver hver handling i normalforløbet et mål som opfyldes? 8. Beskriver hver handling i normalforløbet en fremadskriden i forhold til foregående? 9. Beskriver hver handling normalforløbet tydeligt, hvem/hvad der udfører handlingen? 10. Beskriver ingen af handlingerne i normalforløbet en brugerdialog? 11. Beskriver hver handling i normalforløbet, hvilken information som "sendes". 12. Beskriver alle afvigelser noget, systemet kan opdage? 13. Beskriver alle afvigelser noget, systemet skal reagere på? 14. Generelt: Beskriver use case modellen (det samlede billede af alle use cases), alt hvad der er behov for? 15. Generelt: Kan det verificeres, at det som leveres opfylder det specificerede? 16. Generelt: Kan dette udvikles? Use cases i Qualiware Fordelen ved at lægge use cases ind i Qualiware er, at det er muligt at versionsstyre de forskellige use cases. Qualiwarevejledning til system For at oprette et system: Vælg SystemBoundary placér på det hvide område navngiv objektet. 14
15 Det eksisterende Qualiwaresymbol er ikke, som vi vil have det i KOMBIT. For at indsætte det: Gem følgende fil lokalt på computeren m%20boundary.png Højreklik på det indsatte objekt Vælg Appearance External Source Insert Picture file Og vælg filen, som du gemte før. Qualiwarevejledning til Pakke For at oprette en pakke, vælg Package placér på det hvide område navngiv pakken. 15
16 Qualiwarevejledning til Brugeraktør For at oprette en Brugeraktør, vælg Actor placér på det hvide område navngiv aktøren. Qualiwarevejledning til Systemaktør For at oprette en Systemaktør, vælg Actor placér på det hvide område navngiv aktøren. 16
17 Systemaktør-symbol Systemaktørsymbolet i Qualiware mangler. For at få symbolet ind skal du gøre følgende: Gem følgende fil lokalt på computeren maktør.png Højreklik på den aktør, der er en systemaktør Vælg Appearance External Source Insert Picture file Vælg filen, som du gemte før Qualiwarevejledning til Use case For at oprette en use case, vælg UseCase placér på det hvide område navngiv use casen. 17
18 Qualiwarevejledning til Association mellem aktør og use case For at oprette en association mellem aktør og use case, vælg Relation klik på aktøren klik på use casen vælg Association. Qualiwarevejledning til Relationer (include/extend mellem use cases Include For at oprette en include-relation eller en extendrelation mellem to use cases, vælg Relation klik på den første use case klik på den anden use case vælg Include eller Extend. 18
19 Extend 19
20 Use case skabelon i Qualiware Som nævnt bruger KOMBIT en fast use case skabelon. Use case skabelonen er lagt ind på følgende faneblade, hvis man højreklikker på sin use case og vælger Open : UseCaseInfo BaseretPåFølgendeLovgivni ng IgangsættendeAktører Formål,beskrivelse,afgræns ning Hændelse,forudsætninger, handlinger Slutresultat,sluttilstand Afvigelser,bemærkninger 20
21 Bilag: Use cases i KOMBITs projekter Use cases fra Beskedfordeler projektet: Beskedfordeling Beskedfordelers kernefunktion er fordelingen af beskeder mellem Afsendersystemer og Modtagersystemer. Dette beskrives via en række use cases, der, er vist på Figur 1, og som samlet set udgør funktionaliteten omkring beskedfordeling. Beskedfordeler <<extend>> Modtag besked fra afsendersystem Use case UC-2B-02 Afsendersystem Anvendersystem Beskedfordeling Use case UC-2B-01 <<extend>> <<extend>> Distribuer beskeder Use case UC-2B-03 Afhent beskeder Use case UC-2B-04 Modtagersystem Figur 1 Use cases, som vedrører fordeling af beskeder De fire use cases beskrives i de følgende afsnit. Modtag besked fra Afsendersystem (UC-2B-01) Denne use case beskriver den funktionalitet, Beskedfordeler skal understøtte, at beskeder kan modtages fra et Afsendersystem og klargøres til videre distribution. Beskedfordeler sikrer, at Afsendersystemet har tilladelse til at afsende en given besked, og at forsendelsesinformationer (beskedkuverten) for beskeden er korrekte. Beskedfordeler overtager efter modtagelsen ansvaret for at distribuere beskeden til Modtagersystemerne (se afsnit Fejl! Henvisningskilde ikke fundet.). Use case UC-2B-01 Formål, beskrivelse og afgrænsning Hændelse Startbetingelser Navn: Modtag besked fra Afsendersystem Igangsættende aktører: Afsendersystem Beskedfordeler modtager en besked, som skal distribueres, fra Afsendersystemet, og klargør denne til distribution. Afsendersystemet afleverer besked til Beskedfordeler. Afsendersystemet er tilsluttet Beskedfordeler og har indgået en serviceaftale. Handlinger 21
22 Afsendersystemets beskedaflevering modtages af Beskedfordeler hvilket vil sige Beskedfordeler udfører følgende handlinger: Afsendersystemets beskedaflevering bliver kontrolleret i forhold til sikkerhed og validitet Afsendersystemets besked beriges Afsendersystemets besked bliver signeret såfremt Beskedfordelers opsætning indikerer dette Slutresultat Beskeden er modtaget og klar til Beskedfordelers distribution (jf. use case UC-2B-02). Ansvaret for distribution af beskeden er overdraget til Beskedfordeler. Alternativt Afsendersystmet er markeret inaktiv. Beskedfordeler afviser derfor beskedafleveringen, og en relevant fejlmeddelelse angives til afsendersystemet som svar på beskedafleveringen. Sluttilstand Beskeden er ikke modtaget af Beskedfordeler, og dette er indikeret til aktøren. Bemærkninger En fødereret beskedfordeler kan agere som Afsendersystem, og Beskedfordeler kan dermed modtage beskeder fra denne, til efterfølgende distribuering. Krav 2B-01. Understøttelse af use case UC-2B-01: Modtag besked fra Afsendersystem Kategori: (K) Type: Funktionelt Beskrivelse: Beskedfordeler skal opfylde use case UC-2B-01. Distribuer besked (UC-2B-02) Denne use case beskriver den funktionalitet, Beskedfordeler skal understøtte for, at beskeder kan distribueres til Modtagersystemers dueslag. Før der kan lægges beskeder i et Anvendersystems dueslag skal Anvendersystemet oprette et abonnement. Abonnementet skal udtrykke hvilke beskeder Modtagersystemet ønsker at få indenfor de rettigheder, som tilslutningsaftalen giver. Abonnementet knyttes til et specifikt dueslag, det kan have en gyldighedsperiode, det kan gøres inaktivt, og det kan indeholde abonnementsudtryk og referere til standardabonnementer. Alt dette administreres af tilslutningsparten, jf. use case UC-2B-07. Distributionen af beskeder sker uafhængigt af afleveringen af beskeder fra Afsendersystemer, og baseres på eksplicitte abonnementer fra Modtagersystemer. Tilslutningsparter skal via Beskedfordeler oprette abonnementer forud for, at Modtagersystemer kan modtage de beskeder, Modtagersystemet anser for relevante. Beskedfordeler kan lade beskeder behandle af generelle beskedagenter, før beskederne distribueres til dueslag. De generelle beskedagenter har overfor Beskedfordeler indikeret, hvilke beskeder de (hver især) ønsker at behandle, gennem abonnementsudtryk. Generelle beskedagenter kan ændre beskeders indhold, eller de kan eliminere beskeder eller introducere yderligere beskeder. Generelle beskedagenter der behandler beskeder, opererer på en kopi af beskeden, således at den afleverede besked distribueres, og efterfølgende distribueres den besked, der er behandlet af den generelle beskedagent. Distributionen sikrer herefter, at de rette Modtagersystemer får placeret beskederne i deres dueslag. Distributionsprocessen baseres på indholdet af beskedkuverten i den enkelte besked, samt på de abonnementer, der er oprettet i Beskedfordeler (se afsnit Fejl! Henvisningskilde ikke fundet.). 22
23 Hvis det under distribution af en besked viser sig, at ingen abonnementer matcher beskeden, vil Beskedfordeler placere beskeden i et særligt dueslag, dead letter dueslaget. Dette dueslag sikrer, at beskeder ikke mistes og tilhører altså ikke noget Modtagersystem, men kan indeholde beskeder som alle andre dueslag. Dead letter dueslagets abonnement indeholder ingen abonnementsudtryk eller abonnementsrelationer. Use case Navn: Distribuer besked Igangsættende aktører: Beskedfordeler UC-2B-02 Formål, beskrivelse afgrænsning Hændelse Startbetingelser Handlinger og Beskedfordeler distribuerer modtagne beskeder ved at matche indholdet af beskedernes beskedkuvert med Modtagersystemernes abonnementer, og placere beskeder der matcher abonnementer i tilhørende dueslag. Beskedfordeler har modtaget beskeder fra et Afsendersystem. Afsendersystemets besked er modtaget af Beskedfordeler (UC-2B-01). Der er defineret abonnementer for alle involverede Modtagersystemer (UC-2B-07). Beskedfordeler behandler i modtagelsesrækkefølge modtagne beskeder og distribuerer dem hvilket vil sige: For hver besked matches informationerne i beskedens beskedkuvert mod alle Modtagersystemernes abonnementer Beskeder lægges i alle de Modtagersystemers dueslag, som har aktive, gyldige abonnementer der matcher beskederne Slutresulta t Modtagne beskeder er distribueret ud til alle Modtagersystemer, som abonnerer på beskederne. Beskederne ligger i Modtagersystemernes dueslag. Alternativt: Ved indsættelse af en besked i et dueslag overskrides det pågældende dueslags kapacitet, såfremt en sådan er angivet for dueslaget. Afhængigt af angivelsen på det enkelte dueslag af, hvordan denne situation skal håndteres, fjernes der enten en besked fra dueslaget, eller indsættelsen afvises. Sluttilstan Beskeden er enten d indsat og en anden besked slettet ikke indsat Alternativt: Der er ingen Modtagersystemers abonnementer, der matcher modtagne beskeder, og beskederne placeres derfor i Beskedfordelers dead letter dueslag. Sluttilstan Beskederne ligger i dead letter dueslaget. d Bemærkninger: De ressourcemæssige begrænsninger for overløb i dueslagene kan opsættes af tilslutningsparten (UC-2B- 08). Fødererede beskedfordelere optræder i forbindelse med denne use case som Modtagersystemer med abonnementer og dueslag. Krav 2B-02. Understøttelse af use case UC-2B-02: Distribuer beskeder Kategori: (K) Type: Funktionelt 23
24 Beskrivelse: Beskedfordeler skal opfylde use case UC-2B-02. Aflever besked (UC-2B-03) Denne use case beskriver den funktionalitet, Beskedfordeler skal understøtte, at beskeder kan afleveres til Modtagersystemer. Når en besked er placeret i Modtagersystemets dueslag, leveres den straks til Modtagersystemet. For at undgå tab af beskeder i forbindelse med eventuelle fejlsituationer, opbevarer Beskedfordeler beskederne, indtil leverancen med sikkerhed er gennemført. Først herefter må den leverede besked fjernes fra dueslaget. Såfremt der ikke er forbindelse til Modtagersystemet opbevares beskeder, indtil de kan leveres. Use case Navn: Aflever besked Igangsættende aktører: Beskedfordeler UC-2B-03 Formål, beskrivelse afgrænsning Hændelse Startbetingelser Handlinger og Beskedfordeler leverer beskeder til Modtagersystemet, når disse er distribueret til Modtagersystemets dueslag. Når en besked er leveret, slettes den fra dueslaget. Besked er leveret til Modtagersystemets dueslag (UC-2B-03), eller dueslaget markeres aktivt. Besked er leveret til Modtagersystemets dueslag (UC-2B-03). Dueslaget er markeret aktivt Beskedfordeler leverer nye beskeder hvilket vil sige: At rette en forespørgsel til Modtagersystemet At levere gyldige og ikke-forældede beskederne fra dueslag At sikre sig at beskeden er overført til Modtagersystemet og at modtage Modtagersystemets kvittering for modtagelsen Beskedfordeler markerer leverede beskeder som leveret hvilket vil sige: At beskeder markeres som leverede til efterfølgende fjernelse fra dueslaget og kan således ikke umiddelbart genleveres Slutresulta Beskeder er leveret til modtageren og fjernet fra det pågældende dueslag. t Alternativt: Modtagersystemets dueslag er markeret inaktivt. Beskedfordeler leverer derfor ikke beskeder fra dueslaget. Sluttilstan Der er ikke leveret beskeder til Modtagersystemet eller slettet beskeder i dueslaget. d Bemærkninger: Fødererede beskedfordelere optræder i denne use case som Modtagersystemer. Beskedfordeler leverer beskeder til fødererede beskedfordelere når beskeder placeres i deres dueslag. 24
25 Krav 2B-03. Understøttelse af use case UC-2B-03: Lever besked Kategori: (K) Type: Funktionelt Beskrivelse: Beskedfordeler skal opfylde use case UC-2B-03. Afhent besked (UC-2B-04) Denne use case beskriver den funktionalitet, Beskedfordeler skal understøtte for, at Modtagersystemer kan afhente beskeder. For at lette nogle Modtagersystemers afhentning af beskeder, er det alene på Modtagersystemets initiativ, beskeder udleveres. Beskedfordeler opbevarer derfor beskeder, der endnu ikke er afhentet, i et dueslag, hvorfra beskederne kan afhentes. For at undgå tab af beskeder i forbindelse med eventuelle fejlsituationer, opbevarer Beskedfordeler beskederne indtil beskeden er overført til Modtagersystemet, eller dueslagets kapacitet overskrides. Use case Navn: Afhent besked Igangsættende aktør: Modtagersystem UC-2B-04 Formål, beskrivelse afgrænsning Hændelse Startbetingelser og At understøtte at Modtagersystemet kan afhente beskeder fra egne dueslag i Beskedfordeler.. Når en besked er hentet slettes den fra dueslaget. Modtagersystemet har behov for at afhente beskeder. Beskeder er leveret til Modtagersystemets dueslag (UC-2B-03). Handlinger Modtagersystemet afhenter nye beskeder hvilket vil sige: At forespørge Beskedfordeler efter beskeder At få beskederne udleveret fra dueslag At Beskedfordeler efter afsendelse af beskederne opfatter beskederne som leveret og derfor markerer beskederne som leverede, til efterfølgende fjernelse fra dueslaget At fjerne leverede beskeder Slutresulta t Alternativt: Beskeder er afhentet af modtagersystemet og fjernet fra det pågældende dueslag. Modtagersystemets dueslag er markeret inaktivt. Beskedfordeler afviser derfor forespørgslen om at afhente eller slette beskeder. Sluttilstan d Alternativt: Der er ikke udleveret beskeder til Modtagersystemet eller slettet beskeder i dueslaget, og det er indikeret til Modtagersytemet at dueslaget er inaktivt. Modtagersystemet forespørger om udlevering af beskeder der tidligere er leverede, men som endnu ikke er fjernet fra dueslaget af Beskedfordeler. Sluttilstan d Såfremt beskederne ikke er fjernede fra dueslaget udleverer Beskedfordeler disse til Modtagersystemet. 25
26 Bemærkninger: Krav 2B-04. Understøttelse af use case UC-2B-04: Afhent beskeder Kategori: (K) Type: Funktionelt Beskrivelse: Beskedfordeler skal opfylde use case UC-2B-04. Use cases fra Sygedagpengeprojektet: Opret sag Opret sygefraværssag automatisk (UC-60) Denne use case beskriver den automatiske sagsoprettelse. Hovedparten af funktionaliteten i Sygedagpengeløsningen er automatiseret og use casen igangsættes af systemet (Løsningen). Normalforløbet starter med, at der er hentet en anmeldelse af sygefravær fra et eksterns system (NemRefusion) og slutter med at en ny sag er oprettet. Alternativ 1a beskriver, at Løsningen skal generere en opgave til sagsbehandleren, når startbetingelsen ikke er opfyldt, og den automatiske sagsoprettelse derfor forhindres. Alternativ 3a beskriver, hvad løsningen skal foretage sig, hvis der ikke er registreret nogen borgerhenvendelse af relevans for sagen. Use case UC-60 Navn: Opret sygefraværssag automatisk Baseret på Sygedagpengelovens 38. stk.4 og 35 Igangsættende aktør Løsningen Formål, beskrivelse og afgrænsning Udløsende begivenhed Startbetingelser Den automatiske sagsbehandling startes ved at Løsningen opretter en sygefraværssag, når Løsningen har hentet en anmeldelse fra NemRefusion. Løsningen har hentet en anmeldelse af sygefravær fra NemRefusion. Det anmeldte sygefravær, eksisterer ikke i Løsningen. Handlinger Løsningen 1. opretter en ny sygefraværssag 2. tilføjer relevante metadata 3. søger efter eksisterende henvendelsesnotat for sygemeldte og opretter en opgave til sagsbehandleren herom 4. registrerer en hændelse om at en sygefraværssag er oprettet 5. sender besked om en oprettet sygefraværssag til Sags- og Dokumentindeks, Beskedfordeleren og KMD Sag Slutresultat Der er oprettet en ny sygefraværssag, som indeholder alle data, der er hentet fra NemRefusion Alle relevante metadata (KLE, kassation m.v.) er knyttet til sagen Sagen fremgår af sagsoversigten i Løsningen 26
27 Alternativt: 1a: Oprettelsen fejler da det anmeldte sygefravær allerede er registreret i Løsningen. Løsningen danner en opgave til sagsbehandleren om, at sygefraværssagen er forsøgt oprettet på en allerede eksisterende sag. 3a: der foreligger ikke noget henvendelsesnotat og Løsningen fortsætter uden at oprette en opgave Sluttilstand Bemærkninger: Sagen har sagstilstanden Oprettet Den tilgrundliggende proces er illustreret som P1 i underbilag (Forretningsprocesser). Snitflade #20 til Sags- og Dokumentindeks og snitflade #21 Ydelsesindeks er beskrevet i kapitel 6.4. Opret sygefraværssag manuelt (UC-01) Use casen beskriver den manuelle variant af sagsoprettelsen for de undtagelsestilfælde, hvor forudsætningerne for igangsættelse af den automatiske sagsoprettelse, modtagelsen af en anmeldelse fra NemRefusion, ikke er til stede. Normalforløbet starter med en fysisk henvendelse til sagsbehandleren, som herefter registrerer sagens oplysninger og afslutter med at bekræfte de registrerede oplysninger. Alternativerne 3a og 4a beskriver, hvad sagsbehandleren foretager sig, når handlingerne ikke er relevante. Use case UC-01 Formål, beskrivelse og afgrænsning Navn: Opret sygefraværssag manuelt Baseret på Sygedagpengelovens 38. stk.4 Igangsættende aktør Sagsbehandler i ydelsescenter En sagsbehandler i ydelsescentret skal kunne oprette en sygefraværssag i de tilfælde, hvor en virksomhed ikke kan indberette via NemRefusion og der derfor ikke er modtaget og oprettet en sygefraværssag automatisk. Udløsende begivenhed En sygemeldt er syg på 1. ledighedsdag, hvorfor hverken a-kassen eller nogen arbejdsgiver indberetter sygefraværet. Startbetingelser Sagsbehandleren er logget på Løsningen og har adgang og rettighed til at oprette en sygefraværssag. Løsningen indeholder ikke nogen eksisterende åben sygefraværsag på den sygemeldte, der skal oprettes en sag for. Der foreligger oplysninger, som muliggør oprettelse af sagen. Handlinger Sagsbehandleren 1. indtaster foreliggende sagsoplysninger, som den sygemeldte har afgivet. Løsningen 2. undersøger om der eksisterer henvendelsesnotat på sygemeldte eller virksomheden Sagsbehandleren 3. tilknytter henvendelsesnotatet som journalnotat, hvis det har relevans for sagen 27
28 4. tilknytter eventuelle dokumenter 5. bekræfter de indtastede oplysninger Løsningen 6. sender besked om en oprettet sygefraværssag til Sags- og Dokumentindeks, Beskedfordeleren og KMD Sag Slutresultat Der er oprettet en ny sygefraværssag, som indeholder de sagsdata, som er relevante for sagsbehandlingen, samt de evt. tilknyttede dokumenter. Sagen indeholder relevante metadata (KLE, kassation m.v.) Sygefraværssagen fremgår af sagsoversigten i Løsningen med sagstilstand Oprettet Alternativt: 3a: der eksisterer intet henvendelsesnotat af relevans for sagen og sagsbehandleren bekræfter de indtastede oplysninger 4a: der er ingen relevante dokumenter og sagsbehandleren bekræfter de indtastede oplysninger Sluttilstand Sagstilstanden er Oprettet Bemærkninger: Den tilgrundliggende proces er illustreret som P1 i Underbilag (Forretningsprocesser). 28
Vilkår vedrørende brug af Støttesystemet Beskedfordeler
Vilkår vedrørende brug af Støttesystemet Beskedfordeler 1 Indledning og vejledning Nærværende vejledning beskriver, hvordan it-systemer afsender og/eller modtager beskeder fra Støttesystemet Beskedfordeler,
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
30. april 2013 NOTAT Bilag 12: Anvenderkrav til Støttesystemet Beskedfordeler (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334
Læs mereIntroduktion til Støttesystemet Beskedfordeler
Introduktion til Støttesystemet 1. Om dokumentet Dette dokument formidler et overblik over brugen af den fælleskommunale. Formålet er at give læseren en forståelse af, de væsentligste begreber, forudsætninger
Læs mereFordeling af journalnotater og dokumenter Udkast til løsningsmodel. Marts 2014
Fordeling af journalnotater og dokumenter Udkast til løsningsmodel Marts 2014 1 Indledning Denne præsentation beskriver, på et overordnet plan, følgende områder i forhold til en fremtidig fordelingsmekanisme,
Læs mereScope dokument for Advisservice
18. marts 2013 AHI Scope dokument for Advisservice Indhold 1. Advisservice... 2 2. Advis håndtering i KMD Sag... 2 3. Hændelse og Advis... 3 4. Advis løsningsmodel... 4 5. Abonnementsopsætning... 5 6.
Læs mereSNITFLADER TIL INDEKSER. Præsentation af de fælleskommunale støttesystemernes snitflader til indekser
SNITFLADER TIL INDEKSER Præsentation af de fælleskommunale støttesystemernes snitflader til indekser Introduktion Fokus At give et overblik over: Integration til indekserne Forudsætninger for integration
Læs mereKlik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks
23. maj 2013 HHK/KMJ NOTAT Klik her for at angive tekst. Vejledning til brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk
Læs mereUnderbilag 2Q Vilkår for integration til støttesystemet Klassifikation
Underbilag 2Q Vilkår for integration til støttesystemet Klassifikation 1. Indledning og vejledning Nærværende vejledning beskriver, hvordan Anvendersystemer afsender og/eller modtager objekter til/fra
Læs mereUnderbilag 2O Beskedkuvert Version 2.0
Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...
Læs mereTil kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer
UdbudsVejledning Til kommunernes og Udbetaling Danmarks fremtidige it-udbud vedrørende brug af de fælleskommunale støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog,
Læs mereVilkår for brug af Støttesystemet Sags- og Dokumentindeks
Version 1.0 Vilkår for brug af Støttesystemet Sags- og Dokumentindeks KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og
Læs mereIntroduktion til Støttesystem Sags- og Dokumentindeks
Introduktion til Støttesystem Sags- og Dokumentindeks 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Sags- og Dokumentindeks i den fælleskommunale infrastruktur. Formålet er
Læs mereIntroduktion til Støttesystem Ydelsesindeks
Introduktion til Støttesystem 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af hvilke komponenter,
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
25. april 2013 Klik her for at angive tekst. NOTAT Bilag 14: Anvenderkrav til Støttesystemet Organisation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) kombit@kombit.dk CVR
Læs mere1 Begrebsmodel for Ydelsesindeks
1 Begrebsmodel for Ydelsesindeks Ydelsesindeks skal indeholde metadata om tildelte ydelser, samt nøgler til andre relaterede forretningsobjekter fra Afsendersystemer, således at der kan leveres et tværgående
Læs mere(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)
25. april 2013 NOTAT Anvenderkrav til Støttesystemet Klassifikation (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk
Læs mereIntroduktion til Klassifikation
Introduktion til Klassifikation 1. Om dokumentet Dette dokument formidler et overblik over støttesystemet Klassifikation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse af
Læs mereKlik her for at angive tekst.
30. april 2013 Klik her for at angive tekst. NOTAT Klik her for at angive tekst. Bilag 16: Anvenderkrav til Støttesystemet Ydelsesindeks version 1.0 (Bilag til dagsordenspunkt 8, Kommunale anvenderkrav
Læs mereIntroduktion til Støttesystem Organisation
Introduktion til Støttesystem Organisation 1. Om dokumentet Dette dokument formidler et overblik over Støttesystemet Organisation i den fælleskommunale infrastruktur. Formålet er at give læseren en forståelse
Læs mereVersion 1.0. Vejledning til brug af Støttesystemet Organisation
Version 1.0 Vejledning til brug af Støttesystemet Organisation kombit@kombit.dk CVR 19 43 50 75 Side 1/6 1. Indledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT indkøb af
Læs mereBESKEDFORDELER -ET AF DE OTTE STØTTESYSTEMER. Version 2.0
BESKEDFORDELER -ET AF DE OTTE STØTTESYSTEMER Version 2.0 Støttesystemer er selvstændige it-løsninger, der sikrer, at kommunens fagløsninger kan fungere sammen og få adgang til relevante data. Et støttesystem
Læs mereVejledning til udarbejdelse af jobfunktionsroller og tilknytning til brugersystemroller
Vejledning til udarbejdelse af jobfunktionsroller og tilknytning til brugersystemroller Indhold 1. Introduktion... 2 1.1 Baggrund... 2 2. Adgangsstyring for brugervendte systemer... 3 2.1 Brugervendte
Læs mereVejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer
Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunale Støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder kommunerne i det
Læs mereStøttesystemet Beskedfordeler. Beskedfordeler Et af de otte Støttesystemer
Støttesystemet 1 Et af de otte Støttesystemer 2 Kombit Støttesystemet Hvad er Støttesystemet Beskedefordeler? Abonnér på beskeder om forretningsmæssige hændelser Støttesystemet er det centrale beskedsystem,
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.4.0
SF1460_C Aflever besked - version 2.4.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereKlik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks
30. april 2013 NOTAT Klik her for at angive tekst. Anvenderkrav til Støttesystemet Sags- og Dokumentindeks Indhold: 1. Indledning og vejledning... 3 2. Krav vedr. Systemets anvendelse af Støttesystemet
Læs mereSAPA KRAVSPECIFIKATION v. 0.8. Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL
SAPA KRAVSPECIFIKATION v. 0.8 Overordnede reviewkommentarer fra Kommuneprojektgruppen, ATP, Københavns Kommunes Koncernservice og KL Sags- og partsoverblikket Vise adresser der har adressebeskyttelse Adressen
Læs mereVejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer
3. september 2013 Vejledning til kommunernes fremtidige it-udbud vedrørende brug af de fælleskommunal støttesystemer KOMBIT udarbejder i samarbejde med kommunerne en trin-for-trin Drejebog, der vejleder
Læs mereSF1460_A Modtag besked Integrationsbeskrivelse - version 2.3.0
SF1460_A Modtag besked - version 2.3.0 Kommunernes Data & Infrastruktur - KDI Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereGenerelt om støttesystemerne
Generelt om støttesystemerne Dette afsnit giver et overblik over de enkelte støttesystemer der indgår i Rammearkitekturen. For yderligere information henvises til de udarbejdede kravspecifikationer. Støttesystemerne
Læs mereBrugerskabte data en national service (BSD) - produktbeskrivelse
- 1 Brugerskabte data en national service (BSD) - produktbeskrivelse Brugerskabte data en national service (BSD) - produktbeskrivelse...1 Indledning...1 Formål...1 Beskrivelse...1 Basale krav til det bibliotek/website
Læs mereSAPAs forretningsmæssige behov i relation til Dialogintegration. SAPAs behov for Dialogintegration. Fordele ved brug af dialogintegration i SAPA
26. marts 2014 NOTAT SAPAs forretningsmæssige behov i relation til Dialogintegration Dette notat beskriver SAPAs specifikke forretningsmæssige behov i forhold til integration med relevante ESDH-/fagsystemer,
Læs mereBilag 1: Arkitekturrapport, EDS Hjælpemidler
Bilag 1: Arkitekturrapport, EDS Hjælpemidler (Bilag til dagsordenspunkt 2, Arkitekturrapporter fra Effektiv Digital Selvbetjening) Denne orienteringsrapport udarbejdes for it-projekter i henhold til brug
Læs mereStøttesystemerne. Det er tid til
1 Det er tid til Støttesystemerne 2 Kombit Digitalisering er afgørende for udviklingen af de kommunale kerneopgaver, hvor bedre borgerservice med færre ressourcer er i centrum. Kommunernes mål er at bevare
Læs mereMøde med leverandører om vejledning til anvendelse af kommende fælleskommunale støttesystemer. KL-huset, tirsdag d. 4. juni 2013
Møde med leverandører om vejledning til anvendelse af kommende fælleskommunale støttesystemer KL-huset, tirsdag d. 4. juni 2013 Agenda 1.Mødets formål 2.Der er forskel på leverandører 3.Fælleskommunale
Læs mereINTEGRATION TIL DEN FÆLLESKOMMUNALE ARKITEKTUR
INTEGRATION TIL DEN FÆLLESKOMMUNALE ARKITEKTUR Integrationsform (Serviceplatform [SP]) Gennemstilling Omstilling/redirect Orkestrering Replica/cache Transformation SFTP simpel SFTP med service kvittering
Læs mereMit Sygefravær. Introduktion til den borgervendte selvbetjeningsløsning. September 2015. Version 1.2
Mit Sygefravær Introduktion til den borgervendte selvbetjeningsløsning September 2015 Version 1.2 Indholdsfortegnelse Forord... 3 Når en borger bliver sygemeldt... 4 Meddelelser i Mit Sygefravær... 4 Introduktionssiden...
Læs mereBrugerdokumentation, Beskedfordeler Støttesystemer
Brugerdokumentation, Beskedfordeler Støttesystemer Side 1 af 52 Indholdsfortegnelse Historik... 5 1 Indledning... 6 1.1 Målgruppe for brugermanualen... 6 1.2 Hvad er beskedfordeleren?... 6 1.3 Forudsætninger
Læs mereUnderbilag 14 C: Afprøvningsforskrifter til prøver og tests
Underbilag 14 C: Afprøvningsforskrifter til prøver tests Udbud om levering, installation, implementering, support, drift vedligehold af Borgeradministrativt System (BAS) Indhold underbilag 14 C Afprøvningsforskrifter
Læs mereSF1460_C Aflever besked Integrationsbeskrivelse - version 2.2.2
SF1460_C Aflever besked - version 2.2.2 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 2015-07-01 ehe 0.1 Første version 2015-07-01 ehe 2.1.0 Indarbejdet
Læs mereREVIEW AF KRAVMATERIALE
REVIEW AF KRAVMATERIALE Feedback til kommunerne, 10. og 11. december 2013 Kommunernes Sygedagpengesystem Indledning Ide-camps: Hvad kunne vi godt tænke os? Nov. 2012 Netværksmøde og kick-off på høring
Læs mere10. sept 2013 NOTAT. Integrationsmodel støttesystemer
10. sept 2013 NOTAT Integrationsmodel støttesystemer KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/13 1. Indledning... 3 2. Arkitekturens
Læs mereKrav og vejledning til kommunernes fremtidige it-udbud
Klik her for at angive tekst. Krav og vejledning til kommunernes fremtidige it-udbud I forbindelse med det forestående monopolbrud udarbejder KOMBIT i samarbejde med kommunerne en trin-for-trin drejebog,
Læs mereTM Sund. NemSMS/Digital Post brugervejledning. TM Care a/s Niels Hemmingsens Gade 9, København K
TM Sund NemSMS/Digital Post brugervejledning TM Care a/s Indhold TM Care a/s... 1 Indhold... 2 NemSMS / Digital Post generelt... 3 Opsætning af standardmodtagere... 4 Afsendelse af NemSMS / Digital Post...
Læs mereProcedure for systemtest
LANDBRUGS- OG FISKERISTYRELSEN Procedure for systemtest Retningslinjer for hvordan test udføres i LFST Kontrakt om Testressourcer Underbilag 1c 23. oktober 2017 Version 1.0 En beskrivelse af hvordan test
Læs mereFremsøg sendte og modtagne meddelelser
Fremsøg sendte og modtagne meddelelser Denne vejledning beskriver, hvordan man som myndighed, kan fremsøge sendte og modtagne meddelelser i Digital Post Administrationsportalen, samt hvilke forudsætninger
Læs mereLæsevejledning til review af støttesystemer, marts 2013
Læsevejledning til review af støttesystemer, marts 2013 Kommunerne ønsker en fælleskommunal rammearkitektur, der kan understøtte digitaliseringen og åbne for konkurrence på det kommunale it-marked. Rammearkitekturen
Læs mereIntegration Generelle vilkår og forudsætninger Integrationsbeskrivelse - version 0.1
Integration Integrationsbeskrivelse - version 0.1 rnes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer 201n-nn-nn xxx 0.1 Første version Referencer Ref Titel Kommentarer
Læs mereVejledning i at oprette postkasser i Digital Post. August 2019
Vejledning i at oprette postkasser i Digital Post August 2019 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du skal oprette en postkasse og/eller mapper til postkasser. Du skal
Læs mereDaglig brug af JitBesked 2.0
Daglig brug af JitBesked 2.0 Indholdsfortegnelse Oprettelse af personer (modtagere)...3 Afsendelse af besked...4 Valg af flere modtagere...5 Valg af flere personer der ligger i rækkefølge...5 Valg af flere
Læs mereVejledning i at oprette postkasser i Digital Post. Juli 2016
Vejledning i at oprette postkasser i Digital Post Juli 2016 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du skal oprette en postkasse og/eller mapper til postkasser. Du skal have
Læs mereReleasebeskrivelse KMD Sag. Version 14.5. Nyheder og ændringer i KMD Sag & KMD Sag EDH
Releasebeskrivelse KMD Sag Version 14.5 Nyheder og ændringer i KMD Sag & KMD Sag EDH August 2015 Version 14.5 1 LÆSEVEJLEDNING... 3 2 GENERELT... 3 2.1 Indstilling for gem fællessøgning som defaultvisning...
Læs mereADK 1.0 KRAVSPECIFIKATION
ADK 1.0 KRAVSPECIFIKATION Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.1 23-06-2014 MST Oprettelse af integrationskrav 0.2 25-06-2014 HAH Review for forståelighed og stringens.
Læs mereFælleskommunal infrastruktur - SAPA-seminar, marts Michel Sassene, KOMBIT
Fælleskommunal infrastruktur - SAPA-seminar, marts 2014 Michel Sassene, KOMBIT Agenda 1. Hvorfor fælleskommunal infrastruktur? 2. Hvad kan man med infrastrukturen? 3. Brug af infrastrukturen i kommunen
Læs mereIntroduktion til Digital Post. Digitaliseringsstyrelsen August 2019
Introduktion til Digital Post Digitaliseringsstyrelsen August 2019 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital
Læs mereSTS NETVÆRKSDAGE. Spor 3: Beskedfordeler. 11. og 12. marts 2015. Christian Callsen
STS NETVÆRKSDAGE Spor 3: Beskedfordeler 11. og 12. marts 2015 Christian Callsen SPOR: BESKEDFORDELER PRÆSENTERES AF: Christian Callsen, KOMBIT (ekstern) BAGGRUND: It-arkitekt, bl.a. speciale i hændelsesorientering
Læs mereSecure O matic. Gruppe 5 2. SEMESTERPROJEKT. Udgave. Accepttest-specifikation
Udgave 2 2. SEMESTERPROJEKT Gruppe 5 Secure O matic Accepttest-specifikation Benjamin Sørensen, 02284 Tomas Stæhr Hansen, 03539 Stefan Nielsen, 02829 Mubeen Ashraf, 9279 Hussein Kleit, 9281 SECURE O MATIC
Læs mereVilkår for Dialogintegration
Vilkår for Dialogintegration KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/8 Dokumenthistorik Dato Version Ansvarlig Kommentar til ændringer
Læs mereSAPAs kravspecifikation Læsevejledning. KMJ, 19. marts 2013
SAPAs kravspecifikation Læsevejledning KMJ, 19. marts 2013 Udbudsmaterialets kontrakter og bilag Øvrige bilag A.Ordliste B.Begrebs- og Informationsmodel C.Snitflader (STS og SP) D.Udrulningsbistand E.Overgangsløninger
Læs mereUNDERBILAG 3A.1 TIL KONTRAKT OM EOJ-SYSTEM. Use case Opfølgning
UNDERBILAG 3A.1 TIL KONTRAKT OM EOJ-SYSTEM Use case Opfølgning INSTRUKTION TIL TILBUDSGIVER: Teksten i dette afsnit er ikke en del af Rammeaftalen og vil blive fjernet ved indgåelse heraf. Formål med bilag:
Læs merePensioneringsprocessen/Statens Administration
PENSAB Pensioneringsprocessen/Statens Administration Indhold 1. Overblik over den samlede proces... 2 2. Tildel pensionssag... 3 2.1 Søg i listen [Pensionssager]... 5 2.2 Tildel sag... 5 2.3 Afgiv sag...
Læs mereBilag 1 Tidsplan Version 0.9 05-05-2014 0
Bilag 1 Tidsplan Version 0.9 05-05-2014 0 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 2.1 ETAPER I UDVIKLINGSPROJEKTET... 3 2.1.1 ETAPE I - AFKLARING... 3 2.1.2 ETAPE II ANALYSE, DESIGN,
Læs mereVersion 1.0. Vilkår for brug af Støttesystemet Adgangsstyring
Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT
Læs mereIndholdsfortegnelse for kapitel 2
Indholdsfortegnelse for kapitel 2 Kapitel 2. Analyse.......................................................... 2 Analyse af 2.1...................................................... 2 Analysen af Database.................................................
Læs mere<navn på proces eller use case>
-- AKT 444548 -- BILAG 1 -- [ Bilag B1_Skabelon Integrationstabel ] -- Bilag B1 Integrationstabel Formålet med integrationstabellerne er at danne et samlet overblik over de tekniske integrationer, der
Læs mere23. maj 2013Klik her for at angive tekst. HHK/KMJ. Vejledning til brug af Støttesystemet Adgangsstyring
23. maj 2013Klik her for at angive tekst. HHK/KMJ Vejledning til brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående
Læs mereIntroduktion til Digital Post. Februar 2016
Introduktion til Digital Post Februar 2016 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital Post og hvad der skal
Læs mereMetodehåndbog. Processer. Udarbejdet i fællesskab mellem KL og KOMBIT
Metodehåndbog Processer Udarbejdet i fællesskab mellem KL og KOMBIT Indhold Introduktion... 3 Procesmodellering... 3 Qualiware... 4 Notation for Processer... 4 Pool... 5 Lane... 6 Aktivitet... 6 Hændelse...
Læs mereTM Sund. NemSMS/Digital Post brugervejledning. TM Care a/s Niels Hemmingsens Gade 9, København K
TM Sund NemSMS/Digital Post brugervejledning TM Care a/s 3344 8555 3344 8555 Indhold TM Care a/s... 1 Indhold... 2 NemSMS / Digital Post generelt... 3 Opsætning af standardmodtagere... 4 Afsendelse af
Læs merePensioneringsprocessen/Udbetaling Danmark
Pensioneringsprocessen/Udbetaling Danmark Indhold 1. Overblik over den samlede proces... 2 2. Tildel pensionssag... 3 2.1 Søg i listen [Pensionssager]... 4 2.2 Tildel sag... 5 2.3 Afgiv sag... 5 3. Gennemgå
Læs mereForretningsmæssigt leverandørspor - Serviceplatformen
Forretningsmæssigt leverandørspor - Serviceplatformen Dagsorden 1. Velkomst og ramme for dialogen 2. Forretningsmæssig ramme 3. Arbejdsgange 4. Services på Serviceplatformen 5. Forretningsmæssige muligheder
Læs mereVejledning i at fremsøge sendte og modtagne meddelelser. August 2019
Vejledning i at fremsøge sendte og modtagne meddelelser August 2019 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du skal fremsøge meddelelser i Digital Post. Du skal have én af
Læs mereSAPA Kommunenetværk Øst & Vest. KMJ 28. august 2013, Værløse 29. August 2013, Middelfart
SAPA Kommunenetværk Øst & Vest KMJ 28. august 2013, Værløse 29. August 2013, Middelfart P R O J E K T S T A T U S 1. Kravspecifikation A. Kommuner B. Leverandører 2. Faglige afklaringer i workshops 3.
Læs mereFællesoffentlig beskedmodel version 1.0
Side: 1 Fællesoffentlig beskedmodel version 1.0 Dokumentet indeholder dels en informationsmodel for hændelsesbeskeden og dens miljø, dels en generisk datamodel for hændelsesbeskeden, som kan danne en fælles
Læs mereMit Sygefravær. Introduktion til den borgervendte selvbetjeningsløsning. Marts 2016. Version 1.3
Mit Sygefravær Introduktion til den borgervendte selvbetjeningsløsning Marts 2016 Version 1.3 Indholdsfortegnelse Forord... 4 Når en borger bliver sygemeldt... 5 Brev til den sygemeldte om opgaver i Mit
Læs mereVilkår vedrørende brug af Støttesystemet Adgangsstyring
Vilkår vedrørende brug af Støttesystemet Adgangsstyring 1. Indledning Nærværende vejledning beskriver, hvordan it-systemer skal anvender Adgangsstyring i rammearkitekturen såvel dynamisk som i den daglige
Læs mereIntroduktion til MeMo
Introduktion til MeMo 1. februar 2019 CIU I forbindelse med Digitaliseringsstyrelsens udbud af Næste generation Digital Post løsningen (NgDP) er der udviklet en ny model for udveksling af digitale postmeddelelser,
Læs mereKOMMUNERNES SYGEDAGPENGESYSTEM
KOMMUNERNES SYGEDAGPENGESYSTEM Funktionaliteten i hovedtræk Netværksmøder 5. og 6. november 2013 IKKE KUN IT OG MONOPOLBRUD OGSÅ KOMMUNAL FORANDRING! GLEM HVORDAN DU GØR DET I DAG KSD i kontekst Print
Læs mereLet i gang med NemRefusion for selvstændige
Let i gang med NemRefusion for selvstændige Digital indberetning af syge- og barseldagpenge på Virk.dk Denne lille guide giver dig en introduktion til, hvordan du kan indberette syge- og barseldagpenge
Læs mereVejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge.
Danmarks Statistik, Velfærd 22. januar 203 Børn og Unge, Udsatte børn Vejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge. Indhold Baggrund...2 2 Formål...2
Læs mereSPØRGSMÅL & SVAR TIL UDBUD AF EOJ-SYSTEM TIL HJØRRING KOMMUNE FORHANDLINGS- OG TILBUDSFASEN
SPØRGSMÅL & SVAR TIL UDBUD AF EOJ-SYSTEM TIL HJØRRING KOMMUNE FORHANDLINGS- OG TILBUDSFASEN EU-UDBUD NR. 2016/S 209-378451 (Version 3 af 24. januar 2017) Page 1 of 8 1. Underbilag 3G, case 3 I underbilag
Læs mereVejledning til leverandørers brug af Serviceplatformen
Vejledning til leverandørers brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange...
Læs mereDrejebog for tilslutningsprøve OIO sag
Drejebog for tilslutningsprøve OIO sag Indholdsfortegnelse Ændringer i forhold til forrige version... 3 1 Indledning... 4 1.1 Formål med drejebogen... 4 1.2 Mål med tilslutningsprøven... 4 2 Overordnet
Læs merePensioneringsprocessen for institutioner
Public Release PENSAB Pensioneringsprocessen for institutioner Indhold 1. Overblik over den samlede proces... 2 2. Start en pensioneringssag for en tjenestemand... 3 2.1 Udfyld pensionsskemaet... 3 2.2
Læs mereVejledning til leverandørers brug af Serviceplatformen
Vejledning til leverandørers brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange...
Læs mere1. Administrer brugerkonti. Januar 2011
1. Administrer brugerkonti Januar 2011 Brugervejledning til Dantek MaterialeValg Januar 2011 Copyright 2011 by Dantek A/S Vejledningen er udformet af Mads K. Petersen med bidrag fra Ole Sloth Carlsen.
Læs mereSAGS-, DOKUMENT- OG YDELSESINDEKS. v. Christian Buss Wennemose og Klaus Rasmussen Leverandørdag 26. februar 2019
SAGS-, DOKUMENT- OG YDELSESINDEKS v. Christian Buss Wennemose og Klaus Rasmussen Leverandørdag 26. februar 2019 AGENDA 1. Recap: Hvad er indekserne og hvad kan de bruges til? 2. Tilslutning og Compliance
Læs mereDKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME
DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.
Læs mereBilag 2: Kravspecifikation - Side 1
Bilag 2: Kravspecifikation - Side 1 Use-Cases Syddjurs Kommune betragter den tværgående sundhedsplatform som en del af en større infrastruktur, hvor data flyder mellem forskellige elementer. Dette dokument
Læs mereOS2MO 2.0 Fugl Fønix
OS2MO 2.0 Fugl Fønix OS2MO 2.0 er genoplivet og rulles ud i 18 & 19......men inden produktet rulles ud, gøres brugergrænseflade og kommunikationslag klar (se illustration nedenfor). For at kunne levere
Læs mereSPOR 1: ADGANGSSTYRING
SPOR 1: ADGANGSSTYRING v. Rasmus Halkjær Iversen og Karin Hindø Data- og infrastrukturdage 16. og 19. september 2019 Formål med dagen: At få overblik over hele adgangsstyring med specielt fokus på STS
Læs mereServiceplatformen Vejledning til tilslutning af OS2MO som anvendersystem
Serviceplatformen Vejledning til tilslutning af OS2MO som anvendersystem Indhold 1 Serviceplatformen generelt... 3 1.1 Oprettelse af medarbejdere på Serviceplatform... 3 1.2 Log på STS Administration...
Læs mereBilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer)
Klik her for at angive tekst. Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Krav og vejledning til
Læs meree-konto manual 01.08.2011 e-konto manual Side 1
e-konto manual 01.08.2011 e-konto manual Side 1 Indhold 1. Overordnet beskrivelse... 3 2. Login... 3 3. Se og ret kundeoplysninger... 4 4. Rediger kontaktoplysninger... 6 5. Skift adgangskode... 7 6. BroBizz-oversigt...
Læs mereLøsningsbeskrivelse. Den fælleskommunale Serviceplatform
Løsningsbeskrivelse Den fælleskommunale Serviceplatform Januar 2014 1 Indhold 2 Serviceplatformen... 2 3 Hjemmesiden www.serviceplatformen.dk... 3 3.1 Administrationsmodul... 4 3.2 Servicekatalog... 4
Læs mereDen fælleskommunale Rammearkitektur. - en arkitektur for den kommunale digitalisering
Den fælleskommunale Rammearkitektur - en arkitektur for den kommunale digitalisering Fundament Vision & Strategi Logik Rammearkitektur Fysik Udvikling/Implementering 2 10.6.2014 De 5 digitaliseringsmål
Læs mereKLASSIFIKATION OG ORGANISATION SPOR Netværksdage Støttesystemer og
KLASSIFIKATION OG ORGANISATION SPOR Netværksdage Støttesystemer 11-03-15 og 12-03-15 Hvem er jeg? Denny Christensen Chefkonsulent og IT Arkitekt i KOMBIT Har været teamlead og skribent på bla. kravspecifikationerne
Læs mereSecureAware Compliance Analysis Manual
SecureAware Compliance Analysis Manual Manualen beskriver brugen af SecureAware version 3 Dokument opdateret: november 2009 Om dette dokument Dette dokument er en vejledning i, hvordan du opretter compliance-checks.
Læs mereIntegration SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans) Integrationsbeskrivelse - version 2.1.0
Integration SF1590_A - ØiR - Afsend økonomipostering til ØiR (Finans) Integrationsbeskrivelse - version 2.1.0 Kommunernes Datafællesskab - KDF Versionshistorik Relevans Dato Initialer Version Kommentarer
Læs mereBilag 2: Kravspecifikation
Side 1 af 142. Dokumentets versioner (revisionshistorie) Version Dato Ansvarlig Beskrivelse 0.7 Følgende opdatering er gjort i kravspecifikationen på baggrund af intern review: Kapitel 1 Indledning og
Læs mere