Kravspesifikasjon - anskaffelse av nytt nettsted Melhus kommune For alle krav som stilles, kreves det at leverandøren dokumenterer i hvilken grad og på hvilke måte kravene er oppfylt. Leverandør skal levere en komplett kravbesvarelse som viser om alle krav oppfylles eller inne. Dersom krav må tilpasses eller utvikles, skal leverandør angi estimert utviklingstid og kostnad. Koder B K leverandøren skal levere dette leverandøren bør levere dette leverandøren kan levere dette Oppfylt Leverandør skal her svare ja eller nei. Dersom kravet oppfylles delvis, skal leverandør svare nei, og kommentere i kommentarfeltet hva som kan leveres. Kommentar Leverandør kan komme med en utfyllende beskrivelse, eventuelt henvise til vedlegg.
Innhold Hovedkrav... 3 pesifiserte krav... 3 Innhold skal primært presenteres i HTML 4.01/XHTML 1.0... 3 Tegnsett... 3 Multimediainnhold... 4 Generelt... 4 kalerbar grafikk... 4 Bilder... 4 Lyd... 4 Video... 5 kjema... 5 ak/arkiv... 5 ikkerhet (PKI)... 6 Leverandør skal støtte gjeldende PKI-versjon... 6 E-bøker... 6 Krav til kvalitet... 6 Tilgjengelighet... 6 Artikkel-editor... 7 For innbyggeren... 8 Integrasjoner... 8 tatistikk... 9 Kalender... 9 økemotor... 10 Krav til opplæring, support og prosjektgjennomføring... 11 Krav til design... 11 Teknisk... 12
Hovedkrav 1. Nettstedet skal oppfylle alle obligatoriske og anbefalte forvaltningsstandarder i gjeldende versjon av Referansekatalogen for ITstandarder i offentlig sektor og forskrift om ITstandarder i offentlig forvaltning. http://www.standard.difi.no/forvaltningsstand arder Når obligatoriske og anbefalte forvaltningsstandarder endres, skal det være mulig å oppdatere nettstedet slik at kravene kan oppfylles 2. Nettstedet skal oppfylle minst 35 av suksesskriteriene i Retningslinjer for tilgjengelig webinnhold (WCAG) 2.0. http://uu.difi.no/veiledning/nettsider/krav-tilnettlosninger/krav-wcag Når krav til universell utforming endres, skal det være mulig å oppdatere nettstedet slik at kriteriene kan oppfylles. pesifiserte krav 3. Innhold skal primært presenteres i HTML 4.01/XHTML 1.0 Innhold skal presenteres i HTML 4.01/XHTML 1.0. I det leverandøren avviker fra dette, skal leverandør redegjør for avvik og samtidig opplyse hvilken konsekvens dette vil få i forhold til universell utforming. 4. Tegnsett For å sikre korrekt koding av nettsidene må dette ivaretas: - ette UTF-8 som tegnsett i HTTPprotokollen - ette UTF-8 som tegnsett i HTMLdokumentet (<meta httpequiv="content-type"
content="text/html;charset=utf- 8"/>) - Dersom en benytter databasegenererte sider må en også sørge for at kommunikasjonen med databasen er basert på UTF-8 5. Multimediainnhold Generelt Multimediainnhold skal publiseres i samsvar med Web Content Accessibility Guidelines, WCAG 2.0 Det anbefales å tilfredsstille alle kravene, inklusive AAA-kravene. å langt det er mulig skal adressen direkte til lydfiler, videofiler og -strømmer gjøres enkelt synlig i nettleseren, slik at brukere selv kan velge alternative avspillere. 6. 7. 8. kalerbar grafikk Grafikk skal være skalerbar ved bruk av VG 1.1 (W3C januar 2003). Bilder Bilder skal kunne publiseres ved bruk av JPEG (Joint Photographic Experts Group, IO/IEC 10918-1:1994). Det kan kunne parallellpubliseres i annet format i tillegg, da skal GIF v89a (W3C 1990) benyttes. Det er obligatorisk å publisere bilder (tapsfrie) på offentlige nettsider ved bruk av PNG (Portable Network Graphics, IO/ IEC 15948:2003). Lyd Tapsbasert komprimering Lyd skal kunne pubibliseres ved å bruke minst en av følgende standarder: Vorbis 1 (Xiph.org 2004) innkapslet i Ogg (RFC 3533, IETF 2003), eller
MP3 (IO 11172-3:1993), uten innkapsling (elementærstrøm) Tapsfri komprimering Det er obligatorisk å publisere lyd (tapsfri komprimering) på offentlige nettsider ved å bruke FLAC 1.2.1 (Xiph.org 2007), og det skal kapsles inn i FLACs eget innkapslingsformat eller Ogg (RFC 3533, IETF 2003). Det kan parallellpubliseres i annet format i tillegg. 9. 10. 11. Video Video skal kunne publiseres i minst en av følgende standarder: Videosporet kodet i Theora 1.0 (Xiph.org 2008) og lydsporet i Vorbis 1 (Xiph.org 2004) innkapslet i Ogg (RFC 3533, IETF 2003), eller Videosporet kodet i H.264 (IO/IEC 14496-10:2005) og lydsporet i AAC (IO/IEC 13818-7:2003) innkapslet i MP4 (IO/IEC 14496-14:2003) kjema Elmer 2.1-retningslinjene skal benyttes. Oppfyllelse eller avvik fra Elmer 2- retningslinjene skal dokumenteres. For enkle kontaktskjemaer hvor det ikke er aktuelt å benytte Elmer 2-retningslinjene, stilles det krav om at kravene i WCAG 2.0 er oppfylt på alle nivåer. Nettstedet skal legge til rette for en komplett høringsløsning med skjema for innsending av innspill og tilgang til andre innspill i saken Melhus kommune benytter i dag em og tenersen Prokom som skjemaleverandør. Nettstedet skal kunne benytte ulike skjemaløsninger fra 3.partsleverandører. ak/arkiv
Nettstedet må kunne kommunisere med kommunens sak- og arkivsystem, og leverandøren forplikter seg til å støtte de til enhver tid gjeldende standarder for programmeringsgrensesnitt mot Noarksystemer. 12. Melhus kommune bruker i dag EA 8 som sakog arkivsystem. EA er midlertidig godkjent som Noark-5-løsning. Leverandør skal dokumentere støtte og eventuelle avvik. ikkerhet (PKI) 13. Leverandør skal støtte gjeldende PKIversjon E-bøker Det skal være mulig å publisere e-bøker som EPUB 3.0 14. pråkkoder IO 639 skal legges til grunn for deklarering av språkkoder i HTML. Krav til kvalitet Tilgjengelighet 15. Det skal være mulig å legge alternativ tekst på bilder 16. Lenker skal markeres likt og det skal komme tydelig frem at det er lenker 17. Teksten på nettstedet skal kunne settes til en relativ enhet og det skal være enkelt og intuitivt for brukere av nettstedet hvordan skriftstørrelsen kan endres 18. Datatabeller skal være tilgjengelig 19. Nettstedet skal ikke benytte rammer 20. Menyen skal ikke benytte Javascript eller Flash 21. økefunksjonen skal ikke benytte Javascript eller Flash 22. Kontrastverdiene skal være minst 4,5:1 på normal tekst (opp til 18 pt) og minst 3:1 for stor tekst (over 18 punkt) 23. Det skal være mulig å hoppe over statisk
innhold ved hjelp av «hopp til»-lenke 24. Nettstedet skal skille mellom form og innhold ved bruk av C (cascading style sheets) til både formatering og layout 25. Nettstedet skal ha korrekt deklarering av både hovedspråk og eventuelle andre språk i HTMLelement 26. HTML skal være korrekt kodet 27. All funksjonalitet på nettstedets skal kunne betjenes via tastaturet 28. tørrelsen på startsiden skal være mindre enn 300kB 29. Nettstedet skal kunne oppnå graderingen A i tilpasset test med Yslow 30. Nettstedet skal være tilpasset mobile enheter og ha alle funksjoner tilgjengelig også for disse Artikkel-editor 31. Alt innhold skal automatisk merkes med dato, og når en side/artikkel oppdateres, skal dato automatisk endres til dato for siste redigering 32. Det skal være enkelt å gi beskrivende sidetitler og adresser. Eks: www.melhus.kommune.no/hovin.skole 33. Oppdateringsvarsel B Den som skriver et innlegg, skal kunne legge inn ønske om å motta varsel om at siden bør kontrolleres/oppdateres innen en viss tid, 1 mnd, halvt år, ett år eks. 34. Det skal være mulig å benytte de vanligste nettleserne ved redigering av siden 35. iden skal kunne redigeres via mobile enheter B 36. Administratorrettigheter må være på flere nivå, og det må være mulig å styre adminrettigheter til undersider. Eksempel: Admin-rettigheter til alle sider som starter med www.melhus.kommune.no/hovin.skole men ikke til andre sider 37. Løsningen skal ha støtte for enkel arbeidsflyt, der en produserer en artikkel og en administrator godkjenner 38. Det skal være mulig å laste opp bilder til egendefinert bildestruktrur
39. Det skal enkelt kunne velges om en artikkel skal ha diskusjonstråd, skjema eller annen funksjon knyttet til seg eller ikke. 40. Det skal være enkelt å tidsstyre artikler, både når de skal legges ut og når de ikke lenger skal ligge tilgjengelig. 41. Det skal være mulig å slette feilpubliserte artikler 42. Det skal være mulig å laste opp filer til en egendefinert mappestruktur For innbyggeren 43. Nettstedet skal ha en oversikt over innhold ned til 3. nivå 44. Nettstedet skal ha menymarkering og klikkbar brødsmulesti 45. Nettstedet skal ha nettstedskart 46. Det skal være lett å finne frem på nettstedet 47. Det skal legges til rette for utskrift av innhold 48. Det skal være mulig å abonnere på nyhetsstrøm fra nettstedet gjennom R. R skal være korrekt implementert 49. Kontaktinformasjon skal være godt synlig og plassert på samme sted på alle sider. 50. Det skal være mulig å publisere data i et åpent, K maskinlesbart format for eksempel CV, XML eller JON 51. Lag og foreninger skal selv kunne endre K kontaktopplysninger på nettstedet Integrasjoner Nr Krav Kode Oppfyllt 52. Nettstedet skal legge til rette for dialog gjennom eksempel nettprat/nettmøte/sosiale media osv. (Chat) 53. Det legges til rette for enkel deling av innhold via for eksempel Facebook, Twitter og Instagram (listen er ikke uttømmende) 54. Det skal være mulig å legge til nye funksjoner og integrasjoner i ettertid 55. Nettstedet skal levere en løsning for publisering av innkalling, saksdokumenter og referat/protokoll fra politiske møter. Det skal være mulig å laste ned dokumentene. Melhus kommune benytter i dag EA 8 som saks- og arkivsystem.
Nr Krav Kode Oppfyllt 56. Nettstedet skal levere en løsning for publisering av postjournal i html med fulltekstpublisering av alle inngående og utgående dokumenter 57. Nettstedet skal ha postjournal i html med dokumentbestilling i html-skjema 58. Postjournalen skal ha gode søk- og sorteringsmuligheter 59. Nettstedet skal levere en løsning for utleie av K kommunale bygg 60. Det skal være mulig for å logge inn via IDporten 61. Nettstedet skal kunne integreres mot AD for eksport av telefonliste og e-postadresse over ansatte 62. Nettstedet skal ha en funksjon for K henvendelser/meldinger/kontakt oss til kommunen (bruk av skjema)med direkte innsending fra nettstedet til kommunens postmottak tatistikk 63. Det skal leveres en innebygd statistikkløsning hvor vi kan hente ut statistikk som mest leste artikler, antall sideoppslag, søk (emneord) osv. 64. tatistikkløsningen skal være enkel og informativ, og det skal være mulig å velge periode en ønsker statistikk fra, som f.o.m. dato t.o.m. dato, siste uke, siste måned, siste år osv. 65. Det skal være mulig å benytte seg av eksterne statistikkløsninger Kalender 66. Nettstedet skal inneholde en aktivitetskalender 67. Kalenderen skal ha mulighet for å velge kategori, for eksempel idrettsarrangement, kultur, kommunale avgifter, politiske møter mm. 68. Kalenderen skal være enkel å redigere og B administrere, også via mobile enheter
69. Andre nettsted skal også kunne vise B kalenderen med valgt kategori 70. Kalenderen skal også kunne presenteres i B listeform 71. Det skal være mulig for eksterne å legge B arrangement i kalenderen. like arrangement skal godkjennes av en administrator før de distribueres 72. Eksterne skal kunne legge inn arrangement i B kalenderen uten godkjenning fra administrator ved hjelp av en kode eller lignende 73. Det skal være mulig å synkronisere deler av kalenderen til egen kalender via en lenke, for eksempel skolerute økemotor 74. økefunksjonen skal være lett å finne 75. økefunksjonen skal være plassert på samme plass på alle sider 76. økefunksjonen skal være stor nok til at brukerne kan skrive inn lengre ord eller korte fraser og fremdeles se det som er skrevet inn. Minimum 20 tegn skal være synlig samtidig. 77. Det skal være mulig å velge mellom ulike B presentasjonsformer av trefflisten, for eksempel mulighet for å gruppere eller sortere innholdet, f,eks. etter dato 78. Det skal være mulig å søke på ansatte via B søkefeltet. Det skal kunne søkes på både forog etternavn, telefon og tittel/stilling 79. økefeltet skal ha autofullfør-funksjon B 80. økeresultatet skal presenteres sortert i flere kategorier, for eksempel artikler, ansatte og dokumenter inkludert antall treff i hver kategori 81. økemotoren skal også søke i dokumenter 82. Det skal være mulig å avgrense søket til en B angitt periode
Krav til opplæring, support og prosjektgjennomføring 83. Leverandør skal beskrive og tilby nødvendig opplæring i bruk av nettstedet 84. Leverandør skal ha en prosjektleder som er den kommunen kan forholde seg til fra kontraktsfasen og frem til systemet er i drift 85. Leverandøren skal gi brukerstøtte til kundens system- og opplæringsansvarlige, samt driftsstøtte til driftsansvarlige og superbrukere for systemet hos kunden. Disse skal ha anledning til å kontakte Leverandøren via telefon, mail eller chat. 86. Leverandøren skal levere elektroniske brukerhåndbøker for løsningen på norsk. 87. Tilbudet skal inneholde dokumentasjon på nivå på LA inkludert frister for feilretting for ulike typer feil Krav til design 88. Leverandør skal tilby løsning for utforming av nettstedets design i et tett samarbeid med kommunen 89. Nettstedet skal gjenspeile kommunen, og være rent og enkelt også på undersider. 90. Løsningen skal leveres med ett grunndesign og et sett designmaler (eksempel skole, helsesenter ) 91. Løsningen skal kunne ha forskjellig toppdesign, fargevalg og element for de enkelte designmalene 92. Malene skal inneholde låste designelementer som skrifttyper og størrelser på overskrift, underoverskrift, ingress og brødtekst 93. Det skal være mulig og automatisk tilpasse bildestørrelsen på ingressbilder slik at de følger en fastsatt bildebredde 94. Det skal være enkelt å endre farger på siden 95. Det skal ikke komme frem på nettstedet hvem som har levert løsningen (reklame) 96. Det skal være mulig for kommunen å endre K designelement og maler selv
Teknisk 97. Løsningen kan både leveres som AP og løsning på vår server. Det skal komme frem av tilbudet om løsningen skal/kan installeres på kommunens egen server. 98. Dersom tilbudet leveres med lokal installasjon, må anbefalt maskinvare og programvare beskrives. Dersom AP må leverandøren beskrive sin støtte til oppsett av sertifikater/vpn, som sikrer kommunikasjon mellom kommunens interne systemer og publiserings-løsningen 99. Datalageret skal være underlagt norsk lovgivning og være lagret i Norge 100. Hvis AP skal leverandør oppgi linjehastighet mot Internett, samt redundansløsninger og backup-rutiner. 101. Leverandør skal tilby avtaler som sikrer løpende forvaltning, kontinuerlig oppgradering, og forsikring av løsningens levetid 102. Driftsdokumentasjon. Det skal medfølge nødvendig dokumentasjon for teknisk drift av løsningen. Denne kan være som separat dokumentasjon eller inngå som en del av system-dokumentasjon.