Generella IT-krav vid anskaffning av verksamhetsstöd

1 Serviceförvaltningen Bilaga 4 Generella IT-krav vid anskaffning av verksamhetsstöd

2 Innehållsförteckning: 1. Dokumentinformation...3 1.1. Versionshantering...3 2. Bakgrund, dokumentens roll...4 3. Roadmap...4 4. ÖTP och Sambruk...5 5. Kommunens tekniska vision...6 6. Generellt...7 6.1. Botkyrkas huvudinriktning...7 7. Applikationsarkitektur...8 7.1. Client/server...8 7.2. Webblösningar hanterade av kommunen...8 7.3. Webblösningar som tjänst...9 8. Infrastruktur...10 8.1. Klientdatorer...10 8.1.1. Operativsystem...10 8.1.2. Exekveringsmiljöer...10 8.1.3. Andra beroenden i klienten...10 8.1.4. Citrix...10 8.2. Servrar...10 8.2.1. Operativsystem...10 8.3. Nätverk...11 8.4. Katalog...11 8.5. Metakatalog...11 8.6. Befolkningsregister...11 8.7. E-post...11 8.8. Relationsdatabas...12 8.9. Applikationsserver...12 9. Integration...13 9.1. Användargränssnittsintegration...13 9.2. Single Signon...13 9.3. SOA...13 10. Processhantering/workflow...15 10.1. Generellt...15 10.2. Diariekrav...15 10.3. Driftprocess...15 11. Införandeprojekt...16 11.1. Införandemetodik...16 11.2. Acceptanstest...16 11.3. Användarutbildning...17 11.4. IT-driftpersonalutbildning, dokumentation...17 12. Användbarhet...18 12.1. Generellt...18 12.2. Korrekt webbkodning...18 12.3. Tillgänglighet/anpassning för funktionshindrade...18 12.4. Tillgänglighet/upptid...18 12.5. Prestanda...19 13. Säkerhet...20 13.1. Säkerhetskopiering...20

3 13.2. Generellt...20 13.3. Denial-of-service...20 13.4. Intrång...20 1. Dokumentinformation 1.1. Versionshantering Ändring Utförare Version Datum Skapad Utveckling Utveckling Utveckling Utveckling Utveckling Utveckling Utveckling Förankringsversion Utveckling Mindre formuleringsändring Sven-Håkan Olsson - " - - " - - " - - " - - " - - " - - " - - " - - " - - " - 0.5 0.7 0.8 0.85 0.86 0.87 0.88 0.9 0.91 0.92 0.93 2006-06-08 2006-07-05 2006-08-09 2006-08-22 2006-08-23 2006-08-28 2006-08-31 2006-09-04 2006-09-05 2006-09-17 2006-10-05

4 2. Bakgrund, dokumentens roll Ett antal anskaffanden (upphandlingar, ramavtalsavrop etc) av IT-stöd till verksamheten görs under varje år i Botkyrka kommun. I kravdokumentationen för anskaffandena bör det ingå både funktionella och icke-funktionella krav. Med tanke på att ökad enhetlighet är önskvärd inom IT i kommunen så uppstod idén om föreliggande dokument - en generell teknisk kravspecifikation för IT-stöd. Tanken är att denna kravspecifikation ska kunna återanvändas till många olika upphandlingar. Eftersom de icke-funktionella krav som emanerar från funktionella och andra krav rimligen sällan kan vara helt lika, får specifikationen formen av ett slags palett eller smörgåsbord av krav som utsetts i enlighet med Botkyrkas långsiktiga IT-strategiarbete. Alla kraven menas alltså inte användas samtidigt. Istället planeras det generella dokumentet användas så att vid varje anskaffandetillfälle upprättas en icke-funktionell kravbilaga. Denna pekar ut den konkreta delmängden krav från den generella specifikationen som gäller i just detta anskaffande. Den icke-funktionella kravbilagan kan dessutom innehålla extra krav som behöver ställas i det specifika anskaffandefallet; Funktionella & andra krav ----> Icke-funktionella krav ===> Generella IT-krav I de detaljerade kapiteln nedan används genomgående formuleringen "Krav". Det är alltså sedan upp till varje specifik anskaffning att ange vilka av dessa krav som i det fallet ska appliceras, samt huruvida respektive krav ska ställas som "Bör", "Skall" eller "Beskriv" e dyl. I vissa fall innebär det att några varianter på huvudsakligen samma krav kan stå bredvid varann. Endast krav från Generella IT-krav som refereras i icke-funktionella kravbilagan (eller möjligen annan kravbilaga) ingår alltså i en viss anskaffning. 3. Roadmap Vanligen ställs ett antal Skall-krav och vissa Bör-krav. Förutom att de sistnämnda förstås bör uppfyllas av offerent redan i dagsläget, kan de parallellt tolkas som krav som om något år kan komma att upphöjas till Skall-krav i senare anskaffanden. På samma sätt är det med krav i den generella paletten som i en viss specifik upphandling inte refereras alls - dessa icke-refererade krav ger ändå en indikation till leverantören om vilka krav som torde ställas om några år. (Se även kapitlet om ÖTP.) På detta vis hoppas vi att vi kan ge input i förväg till leverantörernas utvecklingsverkstad om vilka krav leverantörerna bör börja överväga att införa i sin roadmap - så bör hela utvecklings- och anskaffandeprocessen kunna bli billigare och effektivare över tiden.

5 4. ÖTP och Sambruk Botkyrka kommun är medlem i Sambruk, en samarbetsförening för kommuner. Sambruk har bl a tagit fram Öppen Teknisk Plattform (ÖTP) som för tillfället (augusti 2006) förefinns i version 1.2. ÖTP-dokumentet återfinns på www.sambruk.se. ÖTP innehåller också en slags palett, utav arkitekturer och mönster som har potential att vara extra lämpliga för kommuners IT-stöd. Speciellt fokus har hittills lagts på kommunernas publika e-tjänster till medborgare/företag/organisationer etc. Eftersom olika kommuner som är medlemmar i Sambruk har gjort mycket varierande IT-strategiska val fokuserar ÖTP på de saker som är rimligt att majoriteten av medlemmarna kan ha stor nytta av. För att det därmed inte ska bli för snäv "minsta gemensam nämnare" betonar ÖTP interoperabilitet mellan varierande tekniska miljöer och influeras starkt av SOA-tanken (Service Oriented Architecture). En sådan betoning minskar också risken över tiden för varje enskild kommun m a p problematisk inlåsning i en speciell teknikmiljö. ÖTP är främst tänkt att kunna användas som bilaga vid anskaffanden av lösningar som genomförs i kommunalt samarbete via Sambruk. Eftersom ÖTP med nödvändighet är en palett av mönster måste varje specifikt anskaffande peka ut ifall någon variant inom paletten av mönster i just detta fall ska betonas eller t o m vara Skall-krav. I andra anskaffandefall kan det få vara upp till offerenten att välja något av mönstren i paletten. ÖTP har också stor potential att fungera som rådgivning till leverantörers interna tekniska roadmaps för sina lösningar till kommuner, se även kapitlet om Roadmap. Föreliggande Generella IT-krav hänvisar inte direkt till ÖTP men dels är kraven här påverkade av tankarna i ÖTP, dels kan vissa delar vara direkt inkopierade hit. I alla händelser är ÖTP ett lämpligt bakgrundsdokument för en offerent.

6 5. Kommunens tekniska vision (Infogas som bakgrundsinformation) Användarkategorier Medborgare...Företag...Organisationer...Handläggare...Lärare...Föräldrar...Elever etc............ Kanaler Arbetsdator...Hemdator...Webb...Handdator...Smart-telefon...Telefon...Fax...Brev etc Internwebb Externwebb Client/server + lokala appl Användarkataloger Hängränne-appl IT-stöd t medb.kontor IT-stöd t contact center Kommunhuvudwebb Ärendehantering/diarie Ärendeflödesstyrning Nämndsadministration Delade diskar/skrivare E-post Kalender Personliga verktyg mm Stuprörs-appl Successiv övergång till SOA IT-admin Ekonomi Personal/lön Omsorg & stöd Skola Fastighet Koomunledning Förvaltning Informaiton Kultur Bostäder Vatten Brandförsvar Bibliotek Teknik Idrott Renhållning Miljö Arkiv mm Meta katalog LANkataloger AD... Applikationers kataloger EAI; back-end-integration

7 6. Generellt Följande kapitel innehåller krav av olika detaljeringsnivå - ibland relativt detaljerat. Man kan argumentera för att verksamhetsstöd och funktionalitet är det viktigaste och att hur en applikationen ser ut på insidan inte bör vara relevant vid anskaffandena. Emellertid visar erfarenheten att vissa aspekter av en applikations innanmäte blir viktiga för optimering av kommunens nätverk, integration, klientkostnad, serverkostnad, hårdvarukostnad, driftpersonal mm mm. I samband med om det är en byggsten/komponent, inte en hel lösning, som ska anskaffas blir applikationsarkitektur och andra aspekter naturligtvis synnerligen viktigt. Dessutom ökar successivt kraven på integration mellan applikationer och även då blir vissa detaljkrav viktiga. Egentligen är en sådan här kravstrukturering multidimensionell (aspekter skulle återkomma i olika kombinationer), men det skulle bli alldeles för komplext. Istället så har vid överlappsrisk mellan kapitel, varje specifik aspekt helt sonika stoppats in under någon av de tänkbara kategorierna. I enstaka fall görs för tydlighets skulle ändå en "se även"-notering för att underlätta läsandet. 6.1. Botkyrkas huvudinriktning Botkyrka kommun har en inriktning att ligga långt framme vad gäller effektivt IT-stöd inom verksamheten och e-tjänster till omvärlden. Samtidigt är kostnadseffektivitet även viktigt. I grunden ligger en tydlig Microsoft-strategi. Andra lösningar må komma ifråga vid synnerligt speciella krav, men de måste då utvärderas mycket noga och ställas mot saker som skalfördelar via enhetlighet, mot rationalitet i driften etc. 6.1.1. Krav: Att lösningen står i samklang med och stödjer kommunens Microsoftstrategi. (I fallet tjänste-anskaffande räcker det att ev klientände står i denna samklang.) 6.1.2. Krav: Att leverantören inom grundpriset successivt uppgraderar lösningen i enlighet med teknikutvecklingen inom IT. Detta kan t ex röra sig om ändrade intrångsscenarios över tiden och andra säkerhetsrelaterade omvärldsförändringar, successiva uppgraderingar i typiska klientmiljöer (OS, webbläsare, Office-sviter etc) mm mm. Användarförening e dyl bör härvid användas för dialog kring lösningens uppgradering. Beskriv på vilket sätt.

8 7. Applikationsarkitektur Med applikationsarkitektur menas här hur en applikation är uppbyggd, i vilka delar den exekverar, var delarna exekverar och hur den kommunicerar internt (och i förekommande fall externt). Kraven (eller punkterna) inom detta kapitel används troligen ofta som Beskriv-krav, men kan ofta även utgöra Skall- eller Bör-krav. Vissa krav är uttryckta så att de endast utgör Beskriv-krav. 7.1. Client/server 7.1.1. Beskrivkrav: Ifall lösningen är av client/server-typ: Beskriv dess tekniska egenskaper. Framförallt: Hur många skikt det är, vilka de är, hur stor klientdelen är, om SQL-klient i klient eller server krävs (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/server-protokoll som används, ifall lösningen är optimerad för att fungera i ett större WAN, andra beroenden, etc. 7.1.2. Beskrivkrav: Ifall lösningen är av client/server-typ: Beskriv ifall client/server-protokollet är dokumenterat för Botkyrka till syntax och semantik och därmed anropbart från ev annan integration inom kommunen. 7.2. Webblösningar hanterade av kommunen Med "hanterade av kommunen" menas lösningar som kommunen antingen själv driftar eller har en specifikt outsourcad drift för. 7.2.1. Beskrivkrav: Ifall lösningen är av webb-typ: Beskriv dess tekniska egenskaper. Framförallt: Hur många skikt det är inklusive serverdelar, vilka de är, om SQL-klient krävs i server (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/server-protokoll som används, ifall lösningen är optimerad för att fungera i ett större WAN, andra beroenden, etc. 7.2.2. Beskrivkrav: Ifall lösningen är av webb-typ: Beskriv ifall protokollet mellan skikten i serverlösningen är dokumenterat för Botkyrka till syntax och semantik och därmed anropbart från ev annan integration inom kommunen. 7.2.3. Beskrivkrav: Ifall lösningen är av webb-typ men ändå inte endast har en ren webbklient/nätbläddrare utan uppvisar en ökad komplexitet: Beskriv hur klientdelen är beskaffad (Java Applet, ActiveX Control, Flash, Acrobat Reader, AJAX/JavaScript, etc), hur stor klientdelen är, om SQL-klient i klienten krävs (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/serverprotokoll som används från klienten utöver http, ifall lösningen är optimerad för att fungera i ett större WAN, MS Office-integration, andra beroenden, etc.

9 7.2.4. Beskrivkrav: Ifall lösningen är av webb-typ men ändå inte endast har en ren webbklient/nätbläddrare: Beskriv ifall protokollet mellan klient och server är dokumenterat för Botkyrka till syntax och semantik och därmed anropbart från ev annan integration inom kommunen. 7.2.5. Beskrivkrav: Ifall lösningen är av webb-typ och tänks exponeras mot publikt nät (samt möjligen skolelevnät): Beskriv kraven från lösningen på brandvägg (nära server), vilka protokoll/portar yttre brandvägg måste släppa igenom i vilken riktning, vilka protokoll/portar brandvägg innanför DMZ måste släppa igenom i vilken riktning, andra DMZ-krav, etc. 7.2.6. Krav: Att lösningen är av webb-typ, hanterad av kommunen 7.3. Webblösningar som tjänst Med "som tjänst" menas lösningar som en leverantör driftar så att inte kommunen alls behöver vara huvudman för driften (inte ens genom specifik outsourcing), utan kommunen köper endast en funktionalitet, via ett nätverk. Ofta driftas lösningen hos leverantören enligt den s k ASP-modellen (Application Service Provider) för att skalfördelar och lägre kostnader ska uppstå. 7.3.1. Beskrivkrav: Ifall lösningen är av webb-typ, som tjänst, men ändå inte endast har en ren webbklient/nätbläddrare utan uppvisar en ökad komplexitet : Beskriv hur klientdelen är beskaffad (Java Applet, ActiveX Control, Flash, Acrobat Reader, AJAX/JavaScript, etc), hur stor klientdelen är, om SQL-klient i klienten krävs (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/serverprotokoll som används från klienten utöver http, ifall lösningen är optimerad för att fungera i ett större WAN, MS Office-integration, andra beroenden, etc. 7.3.2. Beskrivkrav: Ifall lösningen är av webb-typ, som tjänst, men ändå inte endast har en ren webbklient/nätbläddrare: Beskriv ifall protokollet mellan klient och server är dokumenterat för Botkyrka till syntax och semantik och därmed anropbart från ev annan integration inom kommunen. 7.3.3. Beskrivkrav: Ifall lösningen är av webb-typ, som tjänst: Beskriv vilka krav som ställs på ev brandvägg nära webbklienten. 7.3.4. Krav: Att lösningen är av webb-typ, som tjänst

10 8. Infrastruktur 8.1. Klientdatorer (Se även avsnitt om webbklienter ovan.) 8.1.1. Operativsystem 8.1.1.1. Krav: Att lösningen stödjer Windows 2000 och Windows XP. 8.1.1.2. Krav: Att lösningen stödjer Windows Vista. 8.1.2. Exekveringsmiljöer 8.1.2.1. Beskrivkrav: Kräver lösningen en Java JVM i klienten? 8.1.2.2. Beskrivkrav: Kräver lösningen MS.NET CLR och framework i klienten? 8.1.3. Andra beroenden i klienten 8.1.3.1. Beskrivkrav: Kräver lösningen andra komponenter i klienten utöver operativsystemets medlevererade (t ex speciella drivrutiner, MS Office inkl Outlook, kartprogramvara etc)? 8.1.4. Citrix 8.1.4.1. Krav: Att lösningen stödjer klientexekvering via Citrix. (Gäller även webbklient inom Citrix.) 8.2. Servrar 8.2.1. Operativsystem 8.2.1.1. Krav: Att lösningen stödjer Windows 2000 Server och Windows 2003 Server. 8.2.1.2. Krav: Att lösningen stödjer Windows Vista.

11 8.2.1.3. Krav: Att lösningen stödjer virtualiseringslösningar, t ex VMware eller MS Virtual Server. 8.3. Nätverk 8.3.1. Krav: Att lösningen kan kommunicera med TCP/IP 8.3.2. Krav: Att lösningen kan kommunicera med HTTP och/eller HTTPS Beskriv på vilket sätt, samt ev mer detaljerade krav från lösningen. 8.3.3. Beskrivkrav: Kräver lösningen andra speciella nätlösningar, t ex Ethernet broadcast, UDP? 8.3.4. Beskrivkrav: Kräver lösningen speciell prioritering och QoS-styrning i nätet? 8.4. Katalog 8.4.1. Krav: Att lösningen använder MS Active Directory 2003. Beskriv på vilket sätt, versionskrav, vilket data (t ex användarnamn, lösenord, roller, grupptilhörigheter mm) samt ev mer detaljerade krav från lösningen. 8.4.2. Beskrivkrav: Använder lösningen Active Directory aktivt och online eller importeras AD-data? Kan export i så fall även ske? 8.4.3. Krav: Att lösningen stödjer katalog enligt LDAP v3. 8.5. Metakatalog 8.5.1. Krav: Att lösningen har färdigt stöd för metakataloglösningar. Beskriv vilka metakataloglösningar (t ex MIIS, edirectory) på vilket sätt, versionskrav, vilket data (t ex användarnamn, lösenord, roller, grupptilhörigheter mm) samt ev mer detaljerade krav från lösningen. 8.6. Befolkningsregister 8.6.1. Krav: Att lösningen har koppling till något befolkningsregister för att få in uppdateringar eller göra kontroller, t ex för bostadsadress, folkbokföringsort etc.. Beskriv på vilket sätt, om det är indirekt via någon kommersiell tjänst, samt ev mer detaljerade krav från lösningen. 8.7. E-post 8.7.1. Krav: Ifall lösningen integrerar mot e-post, att MS Exchange 2003 stöds.

12 8.8. Relationsdatabas 8.8.1. Krav: Ifall lösningen använder relationsdatabas, att MS SQL Server stöds. 8.9. Applikationsserver 8.9.1. Beskrivkrav: Ifall lösningen kräver applikationsserver-programvara etc (såsom Java-appserver, speciella cache- eller pooling-lösningar) utöver MS.NET (eller MS Enterprise Services - COM+):

13 9. Integration 9.1. Användargränssnittsintegration 9.1.1. Krav: Ifall lösningen är av webb-typ: Att lösningens webbplats enkelt kan länkas till från kommunens andra webbplatser, och att därmed lösningen både ska kunna utgör ett nytt separat fönster och alternativt iframe/frame. Beskriv hur denna användargränssnittsintegration utformas. 9.1.2. Krav: Ifall lösningen är av webb-typ: Att lösningens användargränssnitt enkelt kan infogas i kommunens andra webbplatser, utan att lösningen utgör ett nytt separat fönster (t ex som MS webpart, Java portlet, iframe/frame etc). Beskriv hur denna användargränssnittsintegration utformas. 9.1.3. Krav: Ifall lösningen är av webb-typ: Att lösningens användargränssnitt kan förses med kommunens logotyp, minst på startsida el motsv. Beskriv hur detta utformas. 9.2. Single Signon 9.2.1. Krav: Att lösningen är förberedd så att s k single signon (SSO) kan tillföras. Detta gäller helst på båda sätten, dvs dels att lösningen kan vara master där inloggnin först sker och annan webb ska kunna ärva inloggningen, dels att lösningen ska kunna vara slav och överta en redan gjord inloggning i annan webb. Beskriv på vad sätt lösningen uppfyller detta. 9.3. SOA Service Oriented Architecture (SOA) är ett mönster framförallt för hur integration mellan olika lösningar och delar kan utföras. SOA tänks numera vanligen utföras med WebServices som en slags API:er (Application Programming Interfaces). En viktig aspekt av SOA är också återanvändning samt framförallt öppenhet i lösningar så att de kan användas flexibelt, som "hängrännor" och tvärfunktionellt inom kommunen och t ex när krav ändrats. SOA ska alltså kunna ge ett smörgåsbord av API-tjänster med vars hjälp nytt/förbättrat IT-stöd snabbt och effektivt ska kunna tas fram. Se även bl a ÖTP v1.2 kap 2.1. Se dessutom även de relaterade frågorna ovan om dokumenterad syntax och semantik i applikationsprotokoll. 9.3.1. Krav: Att lösningen har en öppenhet och därmed kan anropas enligt SOAtanken (omvänt ev även anropa sin omvärld). Beskriv SOA-gränssnitten översiktligt, till teknik, syntax och semantik.

14 9.3.2. Krav: Att SOA-användningen i lösningen följer relevanta standarder. Minimi-nivå: WS-I Basic Profile 1.0 XML 1.0 (Second Edition) XML Schema 1.0 Namespaces in XML 1.0 SOAP 1.1 WSDL 1.1 Beskriv lösningens anpassning till standarder. 9.3.3. Krav: Att SOA-användningen i lösningen i övrigt är utformad för största interoperabilitet mellan teknikmiljöer, genom lämpliga datatypsval, längder mm. Beskriv på vad sätt lösningen strävar till interoperabilitet. 9.3.4. Krav: Att SOA-användningen utförs med s k Standardmeddelanden, åtminstone vid extern integration. Standardmeddelanden är ett sätt att förenkla och harmonisera myndighetskommunikation. Se bl a www.verva.se, E-nämndens riktlinjer 05:01. Se även ÖTP v1.2 kap 4. Beskriv på vad sätt lösningen anpassats till Standardmeddelanden.

15 10. Processhantering/workflow 10.1. Generellt 10.1.1. Krav: Att aktör kan få händelseinformation via kommunens generella ärendehantering då aktiviteter sker i systemet, s k notifiering/avisering. Att aktör kan slå på/av denna notifiering. Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser för vilka aktörer etc. 10.1.2. Krav: Att lösningen har en specifik teknisk anpassning för notifiering/avisering gentemot kommunens valda ärende/workflow-system WM-Data LEX (t ex vid.händelser som etablering av rekryteringsärende, avslutande av rekryteringsärende och inkommen jobbansökan). Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser för vilka aktörer etc. 10.1.3. Krav: Att teknikstöd finns så att aktör kan få händelseinformation via e-post vid vissa aktiviteter sker i systemet, s k notifiering/avisering.. Beskriv på vilket sätt, notifiering för vilka händelser för vilka aktörer etc. 10.2. Diariekrav 10.2.1. Krav: Att lösningen har en specifik anpassning för händelser i lösningen som är av karaktären att de enligt kommunalt regelverk/lag ska diarieföras. I detta fall gentemot kommunens valda system för bl a diarium, WM-Data LEX. Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser etc. 10.3. Driftprocess 10.3.1. Krav: Att lösningsleverantören har en help desk för användare. Ärendestatistik ska kunna erhållas. Beskriv på vilket sätt. 10.3.2. Krav: Att lösningsleverantören har en help desk för teknikärenden för kommunens driftpersonal. Ärendestatistik ska kunna erhållas. Beskriv på vilket sätt. 10.3.3. Krav: Att lösningsleverantören kan ta emot help desk-ärenden (således att utgöra andra linjens support) ifrån kommunens service desk (utgörande första linjens support för användare inom kommunen). Ärendestatistik ska kunna erhållas. Beskriv på vilket sätt.

16 11. Införandeprojekt 11.1. Införandemetodik 11.1.1. Krav: Att leverantören har en införandemetodik för att kunden kan börja använda lösningen. Beskriv översiktligt hur denna ser ut. 11.1.2. Krav: Att leverantören följer Botkyrkas införandemetodik. Se bilaga. Beskriv översiktligt hur denna följs. 11.2. Acceptanstest 11.2.1. Krav: Att acceptanstest utförs. Beskriv leverantörens acceptanstest-procedur. 11.2.2. Krav: Att acceptanstest utförs enligt följande procedur: Före acceptanstest ska modultest separat för varje ingående modul ha gjorts av leverantören, med lyckat resultat (enstaka småfel av klass 3 och 4 må få finnas på publicerad restlista). Före acceptanstest ska också system- och sammanhangstest ha gjorts av leverantören, med lyckat resultat (enstaka småfel av klass 3 och 4 må få finnas på publicerad restlista). Acceptanstest utförs gentemot de funktionella kraven. Testprotokoll ska föras som justeras av både kommunen och leverantören. Acceptanstest utförs gentemot de icke-funktionella kraven. Testprotokoll ska föras som justeras av både kommunen och leverantören. Enstaka småfel av klass 3 och 4 må få finnas på restlista efter att kommunen godkänt acceptanstesten men då ska det finnas en överenskommen handlingsplan för att åtgärda dessa i närtid. Lösningen får inte tas i normaldrift förrän acceptanstesten godkänts av kommunen. Varje testperson som vid tester får ett avvikande resultat från vad som förväntats, skriver direkt en felrapport, i möjligaste mån enligt mall som tillhandahålls elektroniskt. Felrapporten lämnas snarast till kommunens testansvarige Testansvarig sammanställer alla fel eller avvikelser i ett testprotokoll. Felet ska klassas av aktuell testperson och kommunens testansvarige, hur allvarligt de anser det vara, i en skala från 1 4 enligt följande klassning: 1 = Systemstoppande t ex en hängning som gör att man inte kan jobba vidare och som hindrar arbetet 2 = Allvarligt fel t ex felaktig maskinell behandling av informationen som kan få allvarliga följder

17 3 = Mindre allvarligt fel t ex fel som går att gå runt och inte får allvarliga konsekvenser 4 = Irriterande / Skönhetsfel t ex stavfel i ledtexter. Klassningen görs utifrån sannolikheten att felet uppstår, hur ofta det uppstår och hur många som blir drabbade när det uppstår. - Testprotokollet skall kontinuerligt uppdateras och gås igenom tillsammans med leverantören enligt överenskommelse som beskrivs i testplanen. Avsikten är att koppla en problemägare till varje fel-/avvikelse samt en plan för åtgärd och trolig tid för när omtest ska kunna ske. - Testprotokollet ska ligga åtkomligt för information för alla inblandade i testerna, men får enbart uppdateras av system- och testansvarig. Dokument som ska framställas under testarbetet är följande: Testplan - beskriver närmare hur testerna skall genomföras - beskriver vem som har ansvar att testa vad och när det måste vara klart - beskriver samtliga testområden, deras prioritet och när de beräknas vara färdigtestade Testfall - beskrivning av händelser som ska testas - beskriver förutsättningar, vad som skrivas in i systemet och vilka funktionstangenter och liknande knappar man trycker på. - innehåller även förväntat resultat (testfacit). Felrapport - dokumentation för rapportering av fel /avvikelse från testfacit. Testprotokoll - sammanställning av fel som rapporterats i samtliga tester Beskriv leverantörens eventuella acceptanstest-procedurer utöver ovanstående minimikrav på acceptanstest. 11.3. Användarutbildning 11.3.1. Beskrivkrav: Beskriv hur leverantören föreslår att användarutbildning ska gå till. 11.4. IT-driftpersonalutbildning, dokumentation 11.4.1. Beskrivkrav: Beskriv hur leverantören föreslår att IT-driftpersonalutbildning ska gå till. 11.4.2. Krav: Att IT-driftsdokumentation finns, riktad till kommunens IT-personal. Beskriv kort vad den innefattar (t ex klientkonfigurering, brandväggsfrågor i klientänden, ev integrationer med andra system såsom ärende/workflow etc). 11.4.3. Krav: Att lösningen har god dokumentation bestående av funktionell dokumentation och användardokumentation. Beskriv kort vad den innefattar. 11.4.4. Krav: Att lösningen har god teknisk dokumentation. Beskriv kort vad den innefattar.

18 12. Användbarhet 12.1. Generellt 12.1.1. Krav: Ifall lösningen är av webb-typ: Att lösningen stödjer de vanligaste webbläsarna (av nyare versioner), t ex Internet Explorer, Firefox, Opera, Safari. Beskriv vilka webbläsare och versioner som stöds 12.1.2. Krav: Ifall lösningen är av webb-typ: Att lösningen följer "Vägledningen 24-timmarswebben", www.verva.se Beskriv hur vägledningen följs och hur detta verifierats. 12.2. Korrekt webbkodning 12.2.1. Krav: Ifall lösningen är av webb-typ: Att lösningens webbplatser tillämpar W3C:s riktlinjer för webbkodning såsom det uttrycks på validator.w3.org samt jigsaw.w3.org/css-validator. Beskriv hur riktlinjer för webbkodning följs och hur de verifierats. 12.3. Tillgänglighet/anpassning för funktionshindrade 12.3.1. Krav: Ifall lösningen är av webb-typ: Att lösningens webbplatser tillämpar W3C/WAI:s riktlinjer, prioritet 1. Beskriv vilken WAI-anpassning som följs och hur den verifierats. 12.4. Tillgänglighet/upptid 12.4.1. Krav: Tillgänglighet alternativ A: Teknisk tillgänglighet minst kl 07-22 med upptid 99,5% räknat över en vecka, plus övrig tid s k best effort. Beskriv tillgänglighet/upptid hos lösningen. 12.4.2. Krav: Tillgänglighet alternativ B: Teknisk tillgänglighet minst kl 06-24 med upptid 99,5% räknat över en vecka, plus övrig tid s k best effort. Beskriv tillgänglighet/upptid hos lösningen. 12.4.3. Krav: Tillgänglighet alternativ C: Teknisk tillgänglighet minst kl 04-03 med upptid 99,5% räknat över en vecka, plus övrig tid s k best effort. Beskriv tillgänglighet/upptid hos lösningen. 12.4.4. Krav: Tillgänglighet alternativ D: Teknisk tillgänglighet minst kl 04-03 med upptid 99,9% räknat över en vecka, plus övrig tid s k best effort. Beskriv tillgänglighet/upptid hos lösningen.

19 12.5. Prestanda 12.5.1. Krav: Att lösningen har prestanda enligt följande (m a p serverprestanda): Svarstid från sista paket i http-begäran till första i svar, mätt strax utanför leverantörens brandvägg: Att i dygnsgenomsnitt 90% av anropen har svarstid mindre än 3 sek. Gäller både användargränssnitt samt ev maskingränssnitt. Beskriv prestanda hos lösningen. 12.5.2. Krav: Att lösningen har prestanda enligt följande (m a p "tunga" sidor): Svarstid från http-begäran till komplett web-sidöverföring via modem på 56 kb/s anslutet strax utanför leverantörens brandvägg: Att i dygnsgenomsnitt 90% av anropen har svarstid mindre än 30 sek. Beskriv prestanda hos lösningen.

20 13. Säkerhet 13.1. Säkerhetskopiering 13.1.1. Krav: Att lösningen har stöd för säkerhetskopiering (och motsvarande återläggningsrutiner) samt att lösningen utformas så att inte information blir inkonsistent efter återläggning. Beskriv på vilket sätt, versionskrav, ifall data skyddas även emellan säkerhetskopieringstillfällen (ibland kallat deltalogg/transaktionsjournal), ifall data skyddas även mot operatörsmissgrepp (då räcker t ex inte spegling), specifikt kring ev kombination av säkerhetskopiering av relationsdatabas-data och file server-data ifall dessa data är logiskt kopplade till varann, samt ev mer detaljerade krav från lösningen. Beskriv också särskilt ungefär hur lång tid en ev återläggning beräknas ta. 13.2. Generellt 13.2.1. Krav: Att lösningen har stöd för olika rollbaserade rättigheter där användare tilldelas en viss roll eller flera. Att rollerna är utformade så att insynsskydd för känsligt data skapas. Beskriv på vad sätt lösningen uppfyller detta. 13.2.2. Krav: Att inloggningen till lösningen är spårbar via loggning. Beskriv på vad sätt lösningen uppfyller detta. 13.2.3. Krav: Att lösningen har stöd för insynsskydd och manipuleringsskydd vid dataöverföring (kryptering etc). Beskriv på vad sätt lösningen uppfyller detta. 13.2.4. Krav: Att lösningen har stöd för autentisering av inloggande. Beskriv på vad sätt lösningen uppfyller detta. 13.2.5. Krav: Att lösningen har stöd för eid - e-identifiering/e-underskrift (se t ex www.verva.se). Beskriv på vad sätt lösningen uppfyller detta. 13.3. Denial-of-service 13.3.1. Krav: Ifall lösningen är av webb-typ: Att lösningen skyddas mot s k denial-of-service-attacker. Beskriv på vad sätt lösningen uppfyller detta. 13.4. Intrång

21 13.4.1. Krav: Ifall lösningen är av webb-typ: Att webblösningen utförs så att intrång i servermiljön förhindras Beskriv översiktligt på vilket sätt detta sker. 13.4.2. Krav: Ifall lösningen är av webb-typ: Att användargränssnitt utformas så att typiska användaråtgärder för att i klienten förhindra spam, oönskade popups, virus/maskar etc från övriga Internet inte försvåras Beskriv översiktligt på vilket sätt detta sker. 13.4.3. Krav: Ifall lösningen är av webb-typ: Att webblösningen utformas så att intrång via denna lösning i klient eller klientnätverk förhindras. Beskriv översiktligt på vilket sätt detta sker.