Vedlegg 1 Kravspesifikasjon

Transkript

1 Vedlegg 1 spesifikasjon Om feltene fra tilbyder og : Det viktig at leverandørene kort beskriver løsning av de ulike kravene i hvert enkeltpunkt. Der det er mulig ønsker vi at tilbyder oppgir en totalsum for hvert hovedpunkt (uten tilvalg ), og eventuelt for enkeltpunkt der det er naturlig. Alle tilvalg må prises separat, og Distriktssenteret legger inn opsjon på kjøp av disse tjenestene/funksjonene. 1 Overordna krav fra tilbyder 1.1 Følge alle relevante krav i Referansekatalogen for IT-standarder i offentlig sektor. 1.2 Oppnå minst fem stjerner i Difis kvalitetsvurdering for offentlige nettsteder. 1.3 Følge gjeldende WAI standard og WCAG 2.0 for tilgjengelighet på nivå AAA. 1.4 Malverket og løsningen skal validere mot W3C XHTML 1.0 Transitional. 1.5 Løsningen skal være 100 % kompatibel mot MS Internet Eplorer 7.0 eller nyere, Opera 8, Firefo, Google Chrome og Safari (alle versjoner). Brukere med andre nettlesere/eldre versjoner skal få opp en melding om at nettsiden ikke vil vises optimalt og oppfordring om å bytte/oppdatere nettleser. 1.6 Løsningen skal også fritt kunne driftes og videreutvikles av andre leverandører. 1.7 Løsningen skal i størst mulig grad bruke standard produkter basert på åpen kildekode, og det skal i minst mulig grad brukes skreddersydde løsninger. 1.8 Løsingen skal være fleksibel for å kunne møte stadige endringer i behovet for presentasjon av innhold.

2 1.9 Løsningen må legge til rette for at vi skal kunne gjøre endringer i utseende og sidestruktur uten støtte fra leverandør Løsningen skal legge til rette for utstrakt samhandling gjennom sosiale medier og plugins fra andre nettbaserte tjenester. Det skal for eksempel ikke kreve innlogging eller spesielle rettigheter å dele eller like en post. 2 Funksjonelle krav 2.1 Systemet skal ha et fleksibelt navigasjonssystem. Det skal støtte en hierarkisk navigasjonsstruktur og et fritt antall nivåer i navigasjonen. 2.2 Vedlagte informasjonsarkitektur og wireframes danner grunnlag for menyvalgene på nettstedet. Det skal ikke ligge begrensninger som f.eks. at "Hjem"- lenke må ligge på første nivå i menyene. Systemet skal ikke legge begrensninger på hvordan menyene utformes, plasseres på siden eller hvordan de fungerer. 2.3 Administrator skal kunne endre og opprette ulike menyer fra navigasjonsstrukturen og definere regler for hva disse menyene skal inneholde. Eksempelvis skal man kunne lage horisontale menyer, vertikale menyer, ekspanderende menyer, fanenavigasjon, brødsmuler, nettstedskart m.m. av definerte deler av navigasjonsstrukturen. 2.4 Menypunkter skal kunne åpne innholdselementer, andre nettsteder, og popuper i egendefinerte størrelser. 2.5 Systemet skal gjøre det lett å vise hvor i navigasjonsstrukturen man befinner seg. Det skal også være lett å identifisere foreldrene til det aktive menypunktet. 2.6 Det skal være mulig med diskusjons- /kommentarfunksjoner til redaksjonelt Side 2 av 13

3 innhold. Tilbyder må beskrive hvordan dette kan løses med brukerprofiler på distriktssenteret.no, i samhandling med sosiale medier (plugin) eller en kombinasjon av dette. 2.7 Kommentatorer skal ikke være anonyme. Det må være mulig å bekrefte brukeres identitet. Tilbyder må beskrive hvordan dette løses. 2.8 Det må være mulig for administrator å slette og/eller blokkere brukere. 2.9 funksjonalitet må kunne slås av og på for hver enkelt artikkel Systemet må tilby nyhetsfeed av ulike typer innhold og søkeresultat (f.eks. RSS/Atom) Systemet må kunne vise nyhetsfeed fra interne og eksterne kilder (f.eks. RSS/Atom og sosiale plugins) Systemet må kunne verifisere lenker. Brutte lenker må vises i en lett tilgjengelig oversikt Interne lenker (lenker til annet innhold i systemet) må oppdateres automatisk dersom man flytter innholdet det lenkes til Systemet må kunne generere en en oversikt over alt innhold på nettstedet (alle URL-er, filer o.s.v.) med tanke på innholdsanalyse. Tilbyder bes beskrive hvordan dette kan gjøres. 3 Synlighet og universell utforming 3.1 Løsningen skal ha en URL-struktur som er søkemotorvennlig. 3.2 Det må ikke være session ID i URL en. Det skal installeres et ISAP filter (ISAPI Rewrite). Side 3 av 13

4 3.3 Inline style og inline javascript skal ikke brukes. 3.4 Ingen URLer skal være duplikate. 3.5 Det skal installeres analyseverktøy (som Google Webmaster Tools og en Google Analytics konto) med minst 3 brukere. Disse skal sikre anonymisert behandling av brukerne. 3.6 Alle URL skal være tilgjengelig via navigasjon på nettstedet (Ingen form for Javascript i denne klikkbare navigasjonen, rene AHREF linker). 3.7 Meta description skal alltid kunne overstyres i CMS. 3.8 Det skal ikke benyttes noen form for redirects 301 eller 302 på den nye løsningen (utover på midlertidige sider). 3.9 Førstesiden skal ligge på top level domain Filstrukturen bør ha så få subdirectories som mulig Det skal aldri forekomme bruk av subdomener Det skal være mulig med tekstbaserte alternativ til ikke-tekstlig innhold Informasjonen skal være tilgjengelig også når farger ikke vises Siden skal være leselig når den presenteres uten CSS-instruksjoner (all design skal ligge separat CSS-filene). CSS skal benyttes for å skille innhold og utseende Datatabeller skal være korrekt kodet Dersom nettstedet må bruke iframes, skal de være laget på en måte som sikrer tilgjengelighet for alle brukere Nettsidens funksjoner skal være tilgjengelige uten spesielle skript/programmer og plugins. Side 4 av 13

5 3.18 Det skal aldri være mindre enn 5% forskjell i den headesimale fontfargen og bakgrunnsfargen på siden (kombinasjonen av forgrunns- og bakgrunnsfarge skal gi tilstrekklig kontrast) Alle overskrifter på de ulike sidene skal kodes med H1 tag (Str på H1designmessig settes i e: css) Spesialkarakterer eller landsspesifikke tegn skal kodes i rett Character Entities iht valgte standard! (Det er foretrukket at det velges UTF-8) Det skal være mulig å hoppe over faste elementer/menyer og gå direkte til innhold på siden. Dette skal være riktig kodet Hovedspråket skal være angitt i <html> Det skal være mulig for brukere å justere skriftstørrelse i egen nettleser Det skal være mulig å vise en høykontrastversjon av nettsiden Nettstedets funksjoner og elementer skal kunne benyttes også med andre inputenheter enn mus (f.eks tastatur, tale osv) for å sikre tilgjengelighet for alle brukere Skjemaelementer som datafelt, sjekkboks, radioknapper skal knyttes til etikett/label som viser brukeren hvilket element de tilhører. 4 Publisering og administrasjon 4.1 Editor/administrasjon: Systemet skal ha et godt, intuitivt og brukervennlig grensesnitt med lav brukerterskel. Funksjonalitet i systemet skal være lett å finne, lett å forstå, lett å bruke og lett å lære. 4.2 Editor: Løsningen skal ha stavekontroll og Side 5 av 13

6 ordretting. Ordlistene skal kunne tilpasses Distriktssenteret på en enkel måte. 4.3 Editor/publisering: Løsningen skal håndtere flere språk og målformer. 4.4 Nettsidene skal ha visning tilpassa ulike plattformer, som skjerm, nettbrett og smartphone. 4.5 Editor skal vere tilgjengelig fra ulike plattformer, som skjerm nettbrett og telefon. 4.6 Administrator må kunne slette innhold. 4.7 Alt innhold må ha versjonskontroll, og det må være mulig å gjenopprette tidligere versjoner av redaksjonelt innhold. 4.8 Ved endringer må det være mulig å legge inn en fritekst som beskriver endringen. 4.9 Redaksjonelt innhold må ha et fritekstfelt for tilleggsopplysninger som ikke skal være publisert eller tilgjengelig for eksterne brukere Innhold må kunne sorteres, filtreres, kobles slik at det kan presenteres sammenstilt og systematisert Innhold må kunne kategoriseres etter definerte kategorier og tagges med frie emneord Løsningen skal være tilgjengelig for databaseinput Innholdet på skal videreføres i en prosjektdatabase. Det er ønskelig at redaksjonelt innhold i dagens database blir dekket av den nye løsningens hovedinnholdstype, med koblinger til databaseinnholdet. Tilbyder bes beskrive behovet for utvikling av denne databasen Databasen skal inneholde et sett med vurderingsverdier som per i dag ikke skal Side 6 av 13

7 publiseres, men skal kunne brukes ved databaseoppslag backend Publisering: Det skal være mulig å filtrere og søke i databasen, og vise redaksjonelt innhold knyttet til registrerte prosjekt Visning av databaseinnhold skal ha en responstid som er så rask at den ikke svekker brukeropplevelsen Editor/publisering: Systemet må ha en hovedtype innhold (mal) med stor fleksibilitet Tilbyder bes spesifisere hvordan innholdet spesifisert i vedleggene bør tilrettelegges og i hvilken grad det er nødvendig med egne maler for spesielle innholdstyper Det må være mulig for administrator å gjøre tilpasninger i malene. Dersom det er begrensninger i hvilke endringer i malene som kan gjøres uten programmeringsferdigheter bes dette beskrives Editor: Det skal være enkelt å legge bilder inn i postene. Systemet skal tilby enkel bilderedigering (endring av størrelse, bildetekst etc) etter at bilder er lagt inn i post Editor: Alle innholdstyper skal ha støtte for flere typer medier: bilder, bildegalleri, video, lyd etc, i alle vanlige filformater 4.18 Editor: Alle maler må ha WYSIWYG fritekstfelt (editor) med alle vanlige formateringsmuligheter Editor: Alle innholdselementer skal ha tre ulike statuser: kladd, venter og publisert. Kun administrator (redaktør) kan sette en post til publisert, men administrator kan også gi tilgang dette til andre brukere Editor: Det skal være forhåndsvisning av alle innholdstyper. Side 7 av 13

8 4.21 Editor: Enkel klippe/lime-mulighet fra MS Word uten å gi formateringsfeil 4.22 Editor: Det skal være mulig å laste opp filvedlegg til alle typer poster. Filvedlegg skal kunne indekseres. Filvedlegg skal kunne koples til flere innholdselementer Editor: Det må være enkelt å embedde eksternt innhold i postene Editor: Ved oppretting av ny post skal metadata automatisk opprettes Editor: Posttypene må ha støtte for et vilkårlig antall metadatafelt (metadatakravene er beskrevet i et annet kapittel) Editor: Administrator bør kunne legge til hjelpetekster til feltene i CMS Det skal være mulig å skrive ut en post, både før og etter at den er publisert. Utskriften må kunne gjøres i én operasjon (ikke skjermdumper), selv for lange poster. Filvedlegg kan skrives ut i en egen operasjon (evt. fra eget visningsprogram) Det skal være mulig å sette varsling for gjennomgang av innhold Det skal være mulig å bestemme tidspunkt og varighet for publisering av innhold. 5 Bilder og kart 5.1 Systemet må tilby et søkbart mediegalleri og arkiv for opplasta media og filer. (Backend). Det skal være forhåndsvisning av bilder når en bruker søker etter bilder. IPTC-informasjon skal også vises. 5.2 Det skal være enkelt å lokalisere opplastede mediefiler og dokument. (URL med tanke på lenking). 5.3 Alt-tekst skal være obligatorisk ved opplasting av bilder. Side 8 av 13

9 5.4 Administrator må kunne bestemme hva som skal være obligatorisk informasjon for hvert opplastede bilde. 5.5 Det må være mulig å registrere valgfri tilleggsinformasjon for bildene. 5.7 Følgende felter skal automatisk hentes ut fra bilder og lagres i registeret (etter IPTCstandard): 1. Dato 2. Fotograf 3. Fritekst (bildetekst/caption) 4. Bildetittel 5. Emneord (vilkårlig antall) 6. Sted 7. Informasjon om bildets størrelse, både oppløsning og filstørrelse. 5.8 Kart: Det må være mulig å vise et sett med lokasjoner (for eksempel søkeresultat, geografisk tilhørighet for postene) i et kart. Løsningen kan gjerne være basert på Google Maps eller tilsvarende fritt tilgjengelige kartløsninger. 5.9 Kart: Det må være funksjonalitet for å vise tekst, bilde og en lenke (til post) for hver av de markerte lokasjonene i kartet. 6 Søk og metadata 6.1 Systemet skal muliggjøre søk i alt innhold (poster, lister, bilder, video, opplastede filer og brukerprofiler) inklusive tilhørende metadata. 6.2 Søkemotor må oppfylle alle vanlige krav til hurtighet, funksjonalitet, brukervennlighet, filtrering og relevante treff. 6.3 Søkemotor i løsningen må kunne håndtere begge målformer (nynorsk og bokmål) Side 9 av 13

10 (bl.a. synonymordliste) 6.4 Administrator må kunne overstyre søkeresultat om nødvendig (endre rangering på treff) 6.5 Søket må kunne begrenses til deler av nettstedet 6.6 Vi får overvåket alle inntastede søkerord i Google Analytics eller annet analyseverktøy som kommer med publiseringsløsningen 6.7 Systemet skal kunne inkludere metadata i innholdselementer i henhold til Dublin Core-standarden. 6.8 Alle data i felt på postene (de ulike feltene som er definert for posttypene) skal kunne brukes som grunnlag for kategorisering og sortering av poster. 6.9 Emnesetting og kategorisering av innhold skal automatiseres i så stor grad som mulig. Eksempelvis skal systemet automatisk registrere profil -data som genereres av brukerens roller (navn og geografisk tilhørighet) Automatisk genererte metadata skal kunne endres og redigeres av administrator Det skal være mulig for brukeren å få opp en liste over databaseposter der et spesifikt felt har en gitt verdi. Brukeren skal kunne gjøre denne typen oppslag for alle definerte felter Vi skal enkelt kunne vedlikeholde metadata selv 6.13 Malverket skal ha mulighet for differensiert Title Tag pr side. Maks 60 karakterer Ingen TITLE TAGs skal være duplikate (unntak kan være på veldig overordnet nivå) Side 10 av 13

11 6.15 TITLE TAG skal alltid kunne overstyres i CMS 6.16 Alle sider skal ha en differensiert Meta Description automatisert ut i fra et gitt regelsett. Maks 150 karakterer. 7 Tilgang og sikkerhet 7.1 Det skal være tre brukernivåer: Administrator (redaktør): har alle rettigheter Bruker: kan opprette, se og redigere alle typer innhold i alle statuser Ekstern bruker: kan opprette innhold på enkelte områder. Kan kun redigere i eget innhold. Eksterne brukere må kunne verifiseres. 7.2 Administrator skal kunne gi og administrere alle former for tilganger og rettigheter. 7.3 Løsningen skal være sikret mot uautorisert tilgang og angrep. 7.4 Løsningen må håndtere opplysninger etter krav i gjeldende regelverk og føringer fra Datatilsynet. Ut over brukerdata skal ikke løsningen håndtere data som er unntatt offentlighet. 8 Tekniske krav og kostnad over tid 8.1 Eventuell lisenskostnad (per år). 8.2 Gjennomsnittsfrekvens for oppdatering av CMS, kostnad for oppdatering av CMS. 8.3 Kostnad for hosting av distriktssenteret.no. 8.4 Forvaltnings-/vedlikeholdsavtale. Side 11 av 13

12 8.4.1 Løsningen skal hostes og driftes hos leverandør Det må tas backup hver natt. Det må tas vare på sikkerhetskopi pr. natt for siste 5 netter + en kopi pr. måned. Sikkerhetskopier fra backup må kunne hentes ut av driftsleverandøren etter forespørsel Det skal være tilgjengelig et testområde for å prøve ut endringer uten å påvirke daglig drift av nettsiden Distriktssenteret har behov for løpende service og brukerstøtte for løsningen. Brukerstøtten vil primært være innenfor regulær kontortid. Dersom det tilbys uilke modeller for service og brukerstøtte bes det redegjort for disse (modeller og priser). 8.5 Løsningen skal kunne håndtere inntil 50 samtidige påloggede brukere. 8.6 Distriktssenteret ønsker et tett samarbeid med utviklingspartneren fram mot lansering av nytt nettsted. Det er ønskelig med en implementeringsprosess i flere faser. I denne kan det gjøres enkelte justeringer på design og funksjonalitet etter lansering og utprøving på reelle brukere på distriktssenteret.no. Tilbyder bes skissere en samarbeidsløsning og prosess for implementering. 8.7 Størstedelen av det redaksjonelle innholdet på dagens nettsted skal videreføres (inkludert databaseinnholdet i Lokalt utviklingsarbeid). Tilbyder bes skissere løsninger for migrering. 8.8 Tilbyder bes skissere fremdrift for utvikling og implementering av den nye løsningen. 8.9 Administrasjon og editor skal være tilgjengelig via internett, uten å bli hindret av plattform og interne IT-løsninger (f.eks. ASP-løsning) Side 12 av 13

13 8.10 Leverandøren skal legge til rette for at vi skal kunne teste systemet i forbindelse med vurdering av tilbudet. 9 Dokumentasjon og opplæring 9.1 Følgende områder skal være dokumentert: Brukerveiledning for vanlige brukere. Materialet skal leveres i et format som gjør at vi kan presentere det som vårt eget, tilpasse det enkelt til vår grafiske profil og tilpasse det til nivåer på medarbeidere. Materialet skal være pedagogisk og ikke-teknisk oppbygget slik at det er forståelig for vanlige brukere Administrasjonsrutiner og avansert brukerveiledning (for superbrukerne) Feilhåndteringsrutiner/support Systemets grensesnitt og arkitektur 9.2 Leverandør skal sette opp oversikt over anbefalte kurs og opplæring. Dette skal dekke opplæring av: Superbrukere hos Distriktssenteret Vanlige brukere hos Distriktssenteret Beskriv hva som er laget i andre sammenhenger, og angi anbefalt tidsbruk på opplæring for de ulike brukergruppene. Side 13 av 13