Kravspecifikation til Digitalisering på Handicap og Udsatte Voksne området - Anvendelsesvejledning til kommuner

Transkript

1 Kravspecifikation til Digitalisering på Handicap og Udsatte Voksne området - Anvendelsesvejledning til kommuner Version af den 19/5-2011

2 Indholdsfortegnelse 1. Introduktion Om projektet og proces for udarbejdelse af kravspecifikationen Kravspecifikationens anvendelsesområde og systematik Kravspecifikationens bestanddele... 6 Socialministeriet og KL 2

3 1. Introduktion Denne kravspecifikation indenfor Handicap og Udsatte Voksne området er udarbejdet af Socialministeriet og KL efter inddragelse og høring af en række relevante aktører i markedet. En nærmere beskrivelse af processen omkring udarbejdelse af kravspecifikationen fremgår af afsnit 2. Kravspecifikationen stilles gratis til rådighed for kommunerne som et værktøj til beskrivelse af de funktionelle dele af en it-løsning til understøttelse af sagsbehandling af Handicappede og Udsatte Voksne. Kravspecifikationens anvendelsesområde og systematik er nærmere beskrevet i afsnit 3 og kravspecifikationens bestanddele er nærmere beskrevet i afsnit 4. Kravspecifikationen er tænkt som et værktøj til beskrivelse af de funktionelle dele af et it-system til understøttelse af sagsbehandling af Handicappede og Udsatte Voksne. En anskaffelse af systemet - fx ved et EU-udbud - kræver en række yderligere forberedende skridt. Der skal således altid laves en konkret analyse af egne forretningsmæssige behov, samt hvilken it-mæssig arkitektur mv. systemet skal integreres i, inden kravspecifikationen inddrages som teknisk beskrivelse af den ønskede ydelse. Kravspecifikationen skal endvidere altid tilpasses egne ønsker og behov gennem tilføjelse af relevante krav og sletning af ikke relevante krav, fx fordi en funktionalitet allerede er indkøbt, eller af en anden årsag er irrelevant. Desuden skal kravspecifikationen suppleres af en grundig beskrivelse af kommunens it-miljø, herunder driftsmiljø og snitflader til integration. Kravspecifikationen indeholder forslag til en lang række krav, der er tæt relateret til lovgivning, øvrige myndigheders forretningsområder (fx integrationskrav), udredningsmetoden, konkrete standarder samt en række øvrige områder, der må forventes at udvikle sig over tid. Denne version af kravspecifikationen er publiceret den 19. maj 2011, med udgangspunkt i de forhold, der var gældende pr. den 19. maj (med mindre andet er angivet), og brugerne af kravspecifikationen bør til enhver tid sikre, at den omfattede information er aktuel. Der er indsat yderligere vejledning i selve kravspecifikationen, og der henvises til det heri anførte omkring anvendelsen af kravene. Kravspecifikationen er ikke fastlåst i en bestemt udbudsstruktur, idet strategi omkring konkurrenceudsættelse kan være forskellig. Der er således mulighed for selv at vælge, hvordan kravspecifikationen skal inddrages i et udbud herunder, om der skal etableres en struktur med krav, som tilbudsgiver kan tage forbehold over for og mindstekrav, som tilbudsgiver ikke kan tage forbehold over for. Inden kravspecifikationen inddrages i udbudsmaterialet, bør kommunen forholde sig til, om dele af kravspecifikationen skal være krav, som en tilbudsgiver ikke kan fravige. Sådanne krav benævnes ofte mindstekrav. En konsekvens af at gøre et krav til et mindstekrav er, at tilbudsgiverne i deres tilbud ikke kan tage forbehold overfor kravet. Kommunen bør derfor forholde sig til, om det er hele kravet eller kun en del af kravet, der bør være et mindstekrav. Mindstekrav kan også anføres i et særskilt dokument, som vedlægges udbudsmaterialet. Det særskilte dokument skal i givet fald entydigt identificere, hvilke krav tilbudsgiver ikke kan fravige i sit tilbud (mindstekrav). For tiden overvejer projektet, om der skal laves en opdateret version af kravspecifikationen, der indeholder en supplerende beskrivelse af en udbudsstruktur, som kravspecifikationen kan indgå i. I et EU-udbud skal der gennemføres en evaluering af de modtagne tilbud, baseret på tilbudsgivernes tilbud, herunder opfyldelsen af kravspecifikationen. Forud for anvendelsen af kravspecifikationen i et Socialministeriet og KL 3

4 udbud, skal der derfor laves en vurdering af, hvilke dele af kravspecifikationen, som konkret ønskes tillagt særlig vægt. I den forbindelse skal der være fokus på, at det er et udbudsretligt krav, at prioriteringer er gennemsigtigt beskrevet i udbudsmaterialet, fx i form af tydelige tildelingskriterier. Der henvises til Konkurrence- og Forbrugerstyrelsens vejledning om udbud på 2. Om projektet og proces for udarbejdelse af kravspecifikationen Projektet er beskrevet i kravspecifikationens Afsnit A1 (Baggrund og Vision). Der kan desuden hentes information om projektet på og Kravspecifikationen er udarbejdet i perioden fra den 1. november 2010 til den 19. maj I udarbejdelsesprocessen har projektet særligt taget udgangspunkt i følgende arbejde: - Voksenudredningsmetoden, idet systemet netop har til hensigt at understøtte denne, og metoden specificerer de grundlæggende sagsgange på området, samt databehov. Metoden er bedst beskrevet i Metodehåndbogen, der er vedlagt som bilag til kravspecifikationen (jf. underbilag C). - Forprojektets leverance 3 Oplæg om samlet it-arkitektur, hvor den grundlæggende funktionalitet blev beskrevet i samarbejde med en række kommuner. - Datastandardisering på Udsatte Børn og Voksne-området, for at sikre en sammenhæng mellem de to sociale områder i forhold til datastruktur. - Grundlæggende krav til funktionalitet på udsatte børn og unge området (DUBU- projektet) med henblik på genbrug, hvor det er relevant. - Professor Søren Lauesens Vejledning i kravskabelon SL-07 med henblik på at skabe en kravspecifikation, der er tilstrækkelig åbent overfor forskellige tekniske løsninger på kommunernes behov. Kravspecifikationen er udarbejdet i en arbejdsgruppe bestående af: - Socialministeriet: Overordnet projektledelse og koordinering. - Deloitte: It-kompetence, herunder det overordnede redaktøransvar for kravspecifikationen (herunder sikre at den lever op til den ønskede kvalitet og er konsistent). - Deloitte: Forretningskompetence, herunder sikring af samspil mellem kravspecifikation og Voksenudredningsmetode. - KOMBIT: It-kompetence, herunder sikring af genbrug fra arbejde på udsatte børn og ungeområdet, hvor det er relevant. Arbejdet med kravspecifikationen er sket med inddragelse af DHUV-projektets kommuner samt en række øvrige aktører. Inddragelsen er sket i flere spor: - I udformningen af dele, der vedrører de konkrete forretningsmæssige opgaver, systemet skal understøtte, har projektet anvendt medarbejdere fra Gentofte og Århus Kommune. Herudover er indholdet blevet valideret på en workshop med bredere deltagelse fra kommunerne og det har været fremsendt til det kommunale netværk. Derudover har de relevante afsnit været til Socialministeriet og KL 4

5 gennemsyn i fagkontorer i KL og Socialministeriet. Fokus i dette arbejde har særligt været på afsnit C vedrørende Arbejdsopgaver systemet skal understøtte. - I udformningen af de afsnit, der har med økonomistyring o.l. at gøre, har projektet inddraget økonomimedarbejdere og ledere med økonomiansvar fra projektkommunerne, KL, samt KL s økonomistyringsnetværk bestående af en bredere kreds af kommunale økonomichefer. Fokus i dette arbejde har også været afsnit C Arbejdsopgaver systemet skal understøtte. - I udformningen af afsnit med øvrige krav har projektet trukket på it-chefer og konsulenter fra Frederiksberg, Gentofte og Roskilde Kommuner. - I udformning af krav vedrørende tilgængelighed har projektet trukket på IT- og Telestyrelsen samt Danske Handicaporganisationer. Projektet har involveret it-leverandører i projektet. Dette er i første omgang sket ved at invitere til et informations møde i november Invitationen blev blandt andet formidlet gennem organisationen IT-branchen. Projektet har efterfølgende modtaget kommentarer til kravspecifikationen fra en del interesserede it-leverandører, som også er indgået i arbejdet med specifikationen. Søren Lauesen har vejledt projektet i den konkrete anvendelse af SL-07, men det er projektet, der er ansvarlig for den endelige udformning af kravspecifikationen. 3. Kravspecifikationens anvendelsesområde og systematik Det omfattede materiale er målrettet kommuner, herunder kommunefællesskaber, der ønsker at gennemføre et udbud med henblik på anskaffelsen af et DHUV-system. Materialet kan ligeledes anvendes i forbindelse med udvidelse af eksisterende løsninger, eksempelvis som en del af en leveranceaftale, hvor relevante dele af materialet kan genanvendes. Materialet skal ikke ses som et fuldstændigt udbudsmateriale. Ønskes et komplet udbudsmateriale, kan materialet efter en lokal bearbejdning indgå som en del af udbudsmaterialet. Sammenlignes kravspecifikationen med et udbudsmateriale baseret på kontraktstrukturen i K021, så vil kravspecifikationen primært være et bidrag til beskrivelse af indhold svarende til bilag 3 (leverancebeskrivelse) i K02. Tilsvarende er der enkelte driftsrelaterede krav i afsnit H (sikkerhed), hvilket dog er begrænset. Kommuner, der ønsker at anskaffe et DHUV-system gennem anvendelsen af kravspecifikationen, skal altså udarbejde alle øvrige elementer i et udbudsmateriale. Præcis hvilke elementer det er, afhænger af kommunens strategi for konkurrenceudsættelse og det foretrukne tildelingsmæssige koncept, som det også anføres indledningsvist. Som anført i introduktionen kræver en anvendelse desuden altid, at specifikationen tilpasses, udbygges og opdateres til den konkrete sammenhæng, den skal indgå i. Der er ikke nogen øvre grænser for, hvad der kan ændres i kravspecifikationen. Kravspecifikationen stilles til gratis rådighed som et værktøj til beskrivelse af de funktionelle dele af en it-løsning for de kommuner, der vil anvende den. Det er kommunens ansvar at sikre, at kravspecifikationen til enhver tid indeholder de elementer, som ønskes understøttet af leverandørens leverance, og som er vigtige for kommunen. Hertil kommer, at det er kommunen, der vil være kontraktholder, og dermed skal administrere den kontrakt, som indgås med en eventuel leverandør på området. 1 K02 er en standardkontrakt for længerevarende it-projekter, som er udviklet af Dansk IT, IT-Branchen og ITog Telestyrelsen. Socialministeriet og KL 5

6 I denne vejledning er der i afsnit 4 beskrevet en række ikke udtømmende opmærksomhedspunkter i relation til de enkelte afsnit og underbilag. Der gøres tilsvarende opmærksom på, at der løbende i materialet er indsat tekst i rød og kursiv, som er decideret vejledningstekst, der skal slettes eller på anden måde redigeres inden materialet videregives til en eventuel leverandør. Kravspecifikationen tager udgangspunkt i systematikken fra Søren Lauesens SL-072. Der kan læses mere om SL-07 systematikken i Søren Lauesens Vejledning i kravskabelon SL-07 samt i afsnit A.1 (Baggrund og vision) og A.2 (Vejledning til leverandør). De vil derfor ikke blive gennemgået yderligere her. Kommuner, der anvender kravspecifikationen skal anføre, at Dette dokument er baseret på Kravskabelon SL-07. Skabelonen ( Soren Lauesen, 2011) kan frit anvendes i et dokument når blot denne copyright-erklæring står i dokumentet. 4. Kravspecifikationens bestanddele I det efterfølgende gennemgås kravspecifikationens forskellige dele, ligesom en række opmærksomhedspunkter i relation til de enkelte afsnit og underbilag, som dog ikke er udtømmende, beskrives. Afsnit A: Baggrund og vejledning til leverandøren A1. Baggrund og vision Afsnittet beskriver baggrunden for projektet, herunder målsætninger og den overordnede vision. Kommunen kan tilpasse og udbygge dette afsnit med lokal baggrund og vision. A2. Vejledning til leverandør Afsnittet beskriver kravspecifikationens opbygning, herunder systematikken, således at potentielle leverandører har mulighed for at forstå kravspecifikationen. Brugeren af materialet skal sikre, at den leverandørvente vejledning følger det vejledningsparadigme, som gør sig gældende i den valgte udbudsstruktur og udbudsmaterialet. Sædvanligvis vil vejledningen ligeledes adressere, hvordan tilbudsgivere forventes at besvare kravspecifikationen som led i tilbudsafgivelsen. Denne del er ikke medtaget i kravspecifikationen, idet måden, hvorpå tilbudsgiver forventes at besvare, afhænger af den valgte udbudsstruktur og struktur for tilbudsevaluering, som det også nævnes indledningsvist. Afsnit B: Overordnede behov B1. Forretningsmæssige mål I afsnittet anføres de grundlæggende målsætninger med projektet. Målene er alene indsat som orientering til leverandøren, og er altså ikke krav, som leverandøren umiddelbart bør være kontraktuelt forpligtet til at sikre indfrielsen af. Såfremt brugeren af materialet har andre eller supplerende målsætning, så anføres disse. B2. Tidligt bevis for gennemførlighed I afsnittet beskrives en række eksempelkrav til tidligt bevis for gennemførlighed, eller proof of concept, som krav til den tidlige bevisførelse også ofte benævnes. 2 Afsnit A (Vejledning til leverandør) til og med Afsnit I (Brugervenlighed of design). Socialministeriet og KL 6

7 Det skal understreges, at krav til det tidlige bevis ofte vil være beskrevet som et testbilag, eksempelvis bilag 14 (Prøver) i K02, og ikke nødvendigvis i et bilag 3. Det indsatte tekst skal derfor alene ses som inspiration, som kan anvendes ved udarbejdelse af krav til gennemførlighed, eksempelvis i forbindelse udarbejdelsen af et testbilag, eller andre bilag (afhængig af den valgte udbudsstruktur), som typisk vil indeholde krav til prøver. Typisk vil det ikke alene være krav til et tidligt bevis for gennemførlighed, kommunen vil anføre, men også krav til gennemførelse af fx funktions- og overtagelsesprøver. Ofte vil gennemførelsen af prøver være relateret til milepæle, som er bodsbelagte, eller hvor der er mulighed for kontrakthævning. Afsnit C: Arbejdsopgaver systemet skal understøtte I afsnittet beskrives de arbejdsopgaver, som systemet skal understøtte. I afsnittet anvendes opgavesystematikken, som er introduceret i afsnit A. I beskrivelsen af arbejdsopgaverne er der taget udgangspunkt i, at det på bedst mulig vis er forsøgt at give leverandøren en god indføring i, hvilke arbejdsopgaver, der ønskes understøttet. Der er, for ikke decideret at anføre de samme krav flere gange, tilføjet en række centrale krav i afsnit E (fx til print, adviser m.v.), som er relevant for mange delopgaver i afsnit C. I afsnit C gives der beskrivelser af data, der indsamles i opgaverne gennem referencer til underbilag D (Redskaber). Følgende opgaver beskrives: - Modtag henvendelse. Dette vedrører delopgaver inden en sag startes op. - Behandl sag: Dette vedrører de delopgaver, der er direkte knyttet til sagsbehandlingen og som Voksenudredningsmetoden direkte understøtter. Dette er den største og vigtigste opgave, og den er derfor brudt ned i en række adskilte tabeller. Metodehåndbogen (jf. underbilag C) er en vigtig kilde til at forstå opgaven, og der refereres løbende til den. - Planlægning: Denne opgave vedrører sagsbehandlerens og lederens mulighed for at skabe overblik i den enkelte sag og på tværs af sagerne i forhold til den daglige prioritering, planlægning og fordeling af sager. Desuden er der også krav til journalark. - Indberetning til Ankestyrelse og Danmarks Statistik: Denne opgave vedrører muligheden for at kunne opsamle og videresende data i sagsbehandlingen, så det ikke skal foregå manuelt. Denne opgave spiller tæt sammen med afsnittet F (Integrationer). Dette er et af de områder, der indholdsmæssigt kan ændre sig over tid, men KL og Socialministeriet arbejder for at sikre løbende koordination mellem begreberne i metoden og statslige indberetningskrav. - Klagesager: Dette er i princippet blot en variant af sagsbehandling der trækker på en række generelle krav i afsnit E, men der lægges vægt på, at kommunerne kan opsamle ledelsesinformation mht. udfaldet af sagerne. - Økonomisk fremskrivning og sammenhold af forventet og faktisk forbrug: Dette vedrører forskellige opgaver knyttet til økonomistyring på området. Kommunen skal være særligt opmærksom på, at relevansen og udformningen kan være afhængig af, hvilke økonomisystemer kommunen har i forvejen, og at dele af opgaven er afhængig af, at der etableres integrationer. - Beregning af statsrefusion: Dette vedrører muligheden for at beregne statsrefusion på baggrund af kommunens udgifter til såkaldte særligt dyre enkeltsager. For mange kommuner vil det formodentligt være hensigtsmæssigt at foretage beregningen i økonomisystemet. I så fald udtages denne del. Socialministeriet og KL 7

8 - Igangsæt løbende betalinger: Dette vedrører muligheden for at flytte informationer om bevillinger til økonomisystemer med henblik på at sikre betalinger. Denne opgave er særligt afhængig af en integration, jfr. afsnit F (Integrationer) i kravspecifikationen. - Registrer magtanvendelse: Denne opgave vedrører kommunens mulighed for at behandle registreringer og indberetninger af magtanvendelse. - Borger ser sag: Dette vedrører borgerens mulighed for at få adgang til nøgleoplysninger på egen sag. Denne er alene relevant, hvis kommunen ikke bruger ESDH-systemet eller andet system som borgerens indgang til sin sag. - Behandl begæring om aktindsigt: Dette er ligesom klagesager også en variant af sagsbehandling, der trækker på en række generelle krav i afsnit E (Andre funktionelle krav). - Afslut sag: Denne opgave sikrer at de forskellige former for sagsbehandling kan afsluttes. Afsnit D: Data systemet skal anvende I afsnittet præsenteres datamodellen, som er baseret på den datamodel, der anvendes i DUBU. Datamodellen er illustreret i selve afsnittet, men detaljerne, eksempelvis attributbeskrivelser, fremgår af underbilag J (Datamodelbeskrivelse). Datamodellen er vedlagt som en eksemplificering på de data, der skal danne grundlaget i systemet. Da datamodellen sikkert vil ændre sig, er det valgt at tydeliggøre overfor leverandøren, at det er eksempler på data. I øvrigt henvises der til underbilag D (Redskaber), hvor samtlige felter i redskaberne er præsenteret, og det formodes, at det i praksis vil være underbilag D, der er giver leverandøren den bedste forståelse for dataindsamlingsbehovet, mens afsnit D, datamodellen, tydeliggør relationerne mellem datamodellens bestanddele. Datamodellen er beskrevet i UML, og det kræver kendskab til UML, hvis den skal læses og forstås korrekt. Der findes en del litteratur på områder, herunder bl.a. UML specifikationen publiceret af OMG 3. Afsnit E: Andre funktionelle krav Afsnit E indeholder en række funktionelle krav, som ikke adresseres via de øvrige afsnit. Som tidligere anført, er flere krav i afsnittet relevante for flere opgaver i afsnit C, herunder eksempelvis krav til breve, print, informationspakker, m.v.. Afsnittet består af følgende underafsnit: - E1. Komplekse beregninger og regler: Beskrivelse af beregningsregler. - E2. Udskrifter og rapporter: Krav til både faste- og ad-hoc rapporter. Der er en opsplitning i afsnittet, således at der først er en række generelle krav, som er gældende for både ad-hoc- og faste rapporter, og derefter en række specifikke krav målrettet hhv. faste- og ad-hoc rapporter. - E3. Udbygning af systemet: Her stilles krav til, på hvilke områder systemet skal kunne udbygges gennem konfiguration, som kunden selv kan udføre. - E4. Tværgående funktionelle krav: Her beskrives de tværgående krav til opgaverne, der er beskrevet i afsnit C. Typisk er det krav til funktionalitet, som kan bruges i mange opgaver jf. afsnit C. Særligt fremhæves afsnit E4.3, hvor der er indskrevet to løsningsscenarier i forhold til sags- og dokumentområdet, herunder integration til det lokale ESDH-system. Her skal kom- 3 Socialministeriet og KL 8

9 munen vælge, hvilke af de to (hvis ikke et tredje) løsningsscenarie kommunen ønsker at kravstille. De to løsningsscenarier der er indskrevet er hhv. et scenarie hvor alle sager og dokumenter registreres i systemet, og herefter manuelt kan overføres og indlæses til det lokale ESDH system (kaldet det interne arkiv ), og et scenarie, hvor alle sager og dokumenter overføres til det lokale ESDH-system gennem integration (kaldet eksternt sags- og dokumentarkiv ). Såfremt der, fx i relation til eksisterende systemer på området, er behov for konvertering, så bør disse krav ligeledes formuleres i afsnittet. Afsnit F: Systemets integration med eksterne systemer I integrationsafsnittet beskrives krav til hvilke integration, der skal etableres. I afsnittet beskrives indledningsvist en række generelle integrationskrav, hvorefter de systemspecifikke integrationskrav stilles. Generelt skal kommunen være opmærksom på, at det altid bør være de til en hver tid gældende udvekslingsformater, der bør danne grundlag for kravstillelsen. Det er derfor vigtigt at kontrollere rigtigheden af integrationsbeskrivelsen, inden kravspecifikationen anvendes i et konkret udbud. Desuden forudsætter integrationsbeskrivelserne i kravspecifikationen, at snitfladerne til integrationen er kendte standarder, hvilket indebærer, at der ikke må være foretaget lokale omgåelser, ændringer eller tilføjelser hertil. Ofte er dette imidlertid tilfældet. Integrationsbeskrivelserne skal derfor altid uddybes med en entydig beskrivelse af netop det it-miljø, herunder de omgåelser, ændringer eller tilføjelser, der måtte være foretaget i miljøet, som det ønskede system skal integreres i. Tilsvarende skal kommunen være opmærksom på at kræve, hvis det er relevant, at eventuel etablering af VPN og øvrige kommunikationsinfrastrukturelementer ligeledes skal etableres. Kommunen bør herudover særligt være opmærksom på følgende underafsnit: F5 Integration til det lokale ESDH system: Denne integration skal kun skabes, såfremt løsningsscenariet eksternt sags- og dokumentarkiv (jf. afsnit E) ønskes. F6. Integration til økonomisystem: Da der anvendes en række forskellige økonomisystemer, skal det beskrives hvilket økonomisystem, der ønskes integreret til, ligesom en eventuel snitfladebeskrivelse kan vedlægges i et underbilag. F7. Eksternt blanketsystem: Kommunen skal angive navnet på det blanketsystem, der skal integreres til samt vedlægge en snitfladebeskrivelse i et underbilag. Som eksempel på løsning er der valgt at lave en integration til OIB s blanketdel, da denne løsning repræsenterer et standardiseret eksempel på, hvordan integrationen til standardiserede blanketter kan foretages. F9. Dokumentboks og F10. NemSMS: Såfremt kommunen anvender et outputmanagementsystem til håndtering af kommunikationskanaler med borgere, herunder eksempelvis integration til dokumentboks og NemSMS, så bør integrationen formentlig etableres til outputmanagementsystemet, og altså ikke direkte til Dokumentboks og NemSMS, som det kravstilles i de omfattede afsnit. Afsnit G: Teknisk it-arkitektur Afsnittet, som er baseret på SL-07, består ikke af det indhold, der ofte kendetegnes ved teknisk itarkitektur, idet projektet har fokuseret på de overvejende funktionelle dele af SL-07. Socialministeriet og KL 9

10 Afsnittet består af to dele, der henholdsvis 1) beskriver kundens hardware og software og 2) leverandørens krav til software og hardware. Afsnittet er indsat til inspiration, og det må forventes, at det skal tilpasses i væsentligt omfang. I afsnittets første del (G1) kan det anføres, hvilken hardware og software, der anvendes på udbudstidspunktet. Ofte vil disse informationer blive beskrevet i en situationsbeskrivelse, som ofte vil være et underbilag. SL-07 giver dog mulighed for, at det anføres i selve kravspecifikationen. I afsnittets anden del (G2) kan leverandøren anføre eventuelle krav til kundens hardware og software, hvis det ønskes, at leverandøren skal have mulighed for at påvirke dette. Det bør overvejes, om det er hensigtsmæssigt at give leverandøren mulighed for at diktere, hvilket hardware og software kunden skal anskaffe. Afsnit H: Sikkerhed Sikkerhedsafsnittet beskriver de krav, der stilles til leverandøren involveret i udvikling af systemet. Som rammeværk for it-sikkerhedsstyring benyttes ISO Sikkerhedsområder og temaer er defineret med udgangspunkt i OWASPs (Open Web Application Security Project) standard for sikkerhedskrav i udviklingskontrakter. Af samme årsag, så afviger overskriftsstrukturen en smule fra SL-07 standarden. Det skal bemærkes, at sikkerhedsafsnittet er udarbejdet med udgangspunkt i, at kommunen anvender en central løsning til bruger-/rollestyring, som understøtter hele (eller dele af) kommunens systemporteføjle. Såfremt kommunen ønsker, at systemet skal anskaffes som en løsning, hvor bruger- /rollestyringen ikke kan håndteres centralt, så skal dette præciseres i kravspecifikationen. Afsnit I: Brugervenlighed, tilgængelighed og design I1. Effektivitet i dagligt brug Afsnittet indeholder en række eksempelkrav til brugervenlighed og design. Afsnittet er indsat til inspiration, og det må forventes, at det skal tilpasses i væsentligt omfang. Det skal bemærkes, at de listede usability-krav ofte gøres til en del af anskaffelsesforløbets prøver, eksempelvis funktionsprøver eller overtagelsesprøven. Ønskes dette, så bør kravene listes dér hvor beståelseskriterierne, eller kravene, forbundet med prøvernes gennemførelse anføres, hvilket formentlig er i et test- eller prøvebilag, og ikke typisk i kravspecifikationen. I2. Tilgængelighed I afsnittet beskrives en række tilgængelighedskrav, som er udarbejdet med udgangspunkt IT- og Telestyrelsens (ITST) udbudsværktøjskasse. ITST har bistået med udvælgelsen af de relevante krav. Som det fremgår, så er de enkelte krav suppleret med en kildehenvisninger til de kilder, der anvendes som grundlag for udbudsværktøjskassen. Underbilag A: Beregninger I underbilaget henvises til beregningsregler for de enkelte og typer af beregninger. Underbilaget er udarbejdet med udgangspunkt i gældende lovgivninger og blanketter per 11. januar 2011, og skal alene opfattes som en vejledende og dermed ikke udtømmende liste. Det bør naturligvis sikres, at underbilaget indeholder aktuel information. Underbilag B: Løsningsbeskrivelse Underbilaget er oprettet, så kommunerne kan give tilbudsgiver mulighed for at skrive sin eventuelt mere uddybende løsningsbeskrivelse, som led i sin tilbudsgivning. Om dette underbilag ønskes anvendt afhænger af den valgte udbudsstruktur, som det er anført indledningsvist. Anvendes underbilaget, vil det typisk hensigtsmæssig, at opdele løsningsbeskrivelsen i nogle hovedoverskrifter, for på den Socialministeriet og KL 10

11 måde at sikre, at tilbudsgiver beskriver sin løsning i en struktur, som gør den sammenlignelig med øvrige tilbudsgiveres løsninger. Underbilag C: Metodehåndbog I underbilag er metodehåndbogen, som introducerer voksenudredningsmetoden og de tilhørende redskaber, beskrevet. Metodehåndbogen er en vigtig kilde til at forstå opgaverne, og der refereres løbende til den fra afsnit C. Underbilag D: Redskaber Underbilaget giver eksempler på data, som skal registreres i systemet ved at referere fra kravspecifikationen til konkrete felter i underbilaget. Underbilaget er opbygget af dels redskaber fra udredningsmetoden, og dels en række feltoversigter. Underbilag D er det opdaterede datagrundlag, som knytter relationen til de funktionelle krav gennem referencer fra de funktionelle krav. Afsnit D, der indeholder datamodellen, har til formål at beskrive sammenhængen mellem datamodellens klasser, herunder at tydeliggøre hvilke klasser der er defineret eksternt Underbilag E: Lovgivningsmatrice I underbilaget præsenteres en ikke udtømmende liste over lovgivningsfastsatte aktiviteter, samt en mere overordnet matrice for hvilken lovgivning, der kan være særligt relevant i forhold til måden forskellige aktiviteter og faser gennemføres på. Underbilaget er derfor ment som en vejledning til tilbudsgiver i lovgivningsgrundlaget. Underbilaget er udarbejdet med afsæt i gældende lovgivninger og blanketter pr. den 11. januar 2011, og er alene vejledende. I bilaget refereres til centrale lovgivninger vedrørende offentlig forvaltningsvirksomhed, samt sektorspecifik lovgivning. I boksen til højre fremgår de forkortelser der benyttes i den forbindelse. Underbilag F: Struktureret data Underbilaget er udarbejdet som inspiration til muligheder for opsamling af ledelses- og styringsinformation på området. Underbilaget kan således bruges som udgangspunkt til at definere krav til faste rapporter jf. rapportkravene i afsnit F (Andre funktionelle krav), men det må påregnes, at bilaget skal konkretiseres. Underbilag G: Stemplinger i journalark Underbilag er udarbejdet som inspiration til hvilke hændelser og aktiviteter, der kan medføre stemplinger i journalarket. Det er vigtigt at sikre, at systemet, ved krav om en stempling i forbindelse med en hændelse, rent faktisk har det inddata, der er nødvendigt for, at systemet kan registrere hændelsen og dermed udfører stemplingen. Listen omfattet af underbilaget er ikke udtømmende, og viderebearbejdelse er derfor nødvendig. Underbilag H: Ordliste Underbilaget definerer de særlige ord, som anvendes i kravspecifikation, og som ikke er omfattet af begrebsarbejdet jf. underbilag C (Metodehåndbog). Underbilag I: KL blanketter Underbilag indeholder et udkast til OIB blanketter, som der kan tages udgangspunkt i ved ønske (jf. blanketkravet i afsnit E4) om anvendelse af konkrete blanketter. Socialministeriet og KL 11

12 Underbilag J: Databeskrivelser Underbilaget beskriver de enkelte pakker, klasser og attributter omfattet af datamodellen i bilag D (Data systemet skal anvende.) Underbilag K: DUBU datamodel Underbilaget indeholder DUBU datamodellen, som der refereres til fra underbilag J (Datamodelbeskrivelse) fsva. de elementer i DHUV-datamodellen, der er nedarvet fra DUBU. Socialministeriet og KL 12