Vedlegg 1: Kravspesifikasjon. Kravene gjelder både internett og intranett om ikke annet er spesifisert.

Transkript

1 Vedlegg 1: Kravspesifikasjon Kravene gjelder både internett og intranett om ikke annet er spesifisert.

2 Overordnede krav Nr. Krav Ja Må utvikles 1. Løsningen skal fullt ut tilfredsstille Direktoratet for forvaltning og IKT (Difi) sine krav til offentlige nettsteder: Nei Nettstedet skal bruke alternativ bildetekst Lenker skal skille seg ut fra vanlig tekst Skriftstørrelsen skal kunne endres Datatabeller skal være tilgjengelige og skal kunne kodes med th, table summary og table content via grafisk grensesnitt Rammer må bli brukt på en måte som reduserer ulempene Meny og søk skal fungere uten ekstra utvidninger Kontrasten på nettstedet er tilstrekkelig, Statisk innhold skal kunne hoppes over Nettstedet skal bruke CSS (stilsett) som skiller mellom form og innhold Nettstedet sitt språk skal være oppgitt HTML er korrekt kodet på nettstedet Nettstedet skal være lett å laste Innholdet skal kunne merkes med dato Nettstedet har søkefunksjon Søkeresultat blir presentert på en god måte Innholdet er presentert på andre språk enn norsk Hovedmenyen er konsistent på hele nettstedet Nettstedet har markert hvor man er i nettstedsstrukturen Nettstedet har lagt til rette for utskrift av innholdet Nettstedet har en oversikt over innholdet Nettstedet har lagt inn relevante metadata Nettstedet har beskrivende sidetitler og adresser Teksten på nettsidene er enkel å lese Nedlastbare dokument er publisert som PDF eller ODF Nettstedet legger til rette for forenklet informasjonsflyt Nettstedet har strukturert informasjon om kjerneoppgaver Nettstedet har sentral kontaktinformasjon Nettstedet har sentral egeninformasjon Nettstedet legger til rette for innsyn i postjournal, saker og møter Nettstedet legger til rette for elektroniske høringer Nettstedet utnytter teknologien til å lage nyttige løsninger 1

3 Nettstedet har skjema for elektronisk innsending Nettstedet har innloggingsbasert selvbetjening Funksjonalitetskrav 2. Generell funksjonalitet Løsningen skal ha en godkjenningsmulighet. Med dette menes at løsningen skal ha støtte for enkel arbeidsflyt, herunder godkjenning av artikler, for eksempel der redigerer produserer og ansvarlig redaktør godkjenner Alt innhold skal automatisk merkes med innholdsansvarlig og dato. Dersom en artikkel endres i ettertid, skal endringsdato fremkomme Artikkellister skal være sortert etter publiseringsdato, og de skal kunne deles opp i flere sider med et gitt antall artikler per side. (Se eksempel 7, vedlegg 2, - Oversikt over planer og prosjekter ) Sluttbrukere skal selv kunne sortere artikkellister ved å klikke på kolonneoverskriftene. (Se eksempel 7, vedlegg 2, - Oversikt over planer og prosjekter ) Publiseringsverktøyet skal ha støtte for å avdekke lenkebrudd Alle artikler og sider skal være tilrettelagt for utskrift. Artikler må ha en skriv ut knapp som renser innholdet for alle menyer og skriver ut innholdet Løsningen skal ha støtte for presentasjon av innhold på flere språk. Det skal være enkelt å skifte mellom ulike språk, både for forfattere og for brukere av hjemmesiden. Sider med annet språkinnhold skal kunne kodes med riktig LANG kode i det grafiske grensesnittet Nettportalen skal leveres med en nettsti/brødsmulesti Fremtidige endringer i innholdsstrukturen skal ikke resultere i at gamle URL er slutter å fungere Løsningen skal ha mulighet for å lage et nyhetsarkiv som sammenfatter tidligere publiserte artikler. Arkivet skal være kronologisk strukturert, og utlisting skal ta utgangspunkt i uker All informasjon på hjemmesiden skal være tilgjengelig også når farger ikke vises. 2

4 3. Administrasjon Det må kunne defineres et sett med roller som er hensiktsmessig for verktøyet. Tilgang til funksjonalitet i verktøyet gis på bakgrunn av hvilken rolle en bruker er tilordnet. De ulike rollenes tilgang og hvilke roller en bruker er tilordnet må kunne endres. Det må eksistere ulike sett med roller på hvert av nettstedene som skal inngå i løsningen. For all tilgang til applikasjonens objekter må det verifiseres at bruker har rettigheter til å aksessere objektet Brukerhåndtering og aksess til intranettet og publiseringsverktøyet skal knyttes mot Rogaland fylkeskommunes eksisterende edirectory Ansvarlige redaktører skal på en enkel måte ha mulighet til å vedlikeholde ulike menyer som kan være plassert ulike steder på intra- og internettsidene Ansvarlig redaktør/administrator skal kunne endre tekst- og grafisk innhold i gitte faste sideelementer, som for eksempel teksten i kolofonen nederst på siden (footer/bunntekst) (Se vedlegg 2, eksempel 1 - Footer) Den samme tekniske løsningen skal kunne benyttes av flere nettsteder samtidig, slik at sentraladministrasjonen i Rogaland fylkeskommune kan drifte nettsidene til de skoler og virksomheter som ønsker det Det må kunne gis begrenset tilgang i publiseringsverktøyet til redigerere med ansvar for å redigere og opprette innhold i enkelte kategorier Det skal være mulig å gi tilgang til enkelte redigerere å publisere flere driftsmeldinger. (Se vedlegg 2, eksempel 11 Melding fra IKT) Løsningen skal kunne krysspublisere innhold mellom intra- og internett, delportal og hovedportal, slik at man slipper å lagre offentlig informasjon flere steder Det skal være mulig å åpne og lukke deler av intranettet for ulike grupper av brukere Løsningen skal støtte ubegrenset antall kategorisider og delportaler Det skal være mulig å velge eget design/annen mal for ulike kategorisider og delportaler Publiseringsverktøyet skal leveres med innebygd statistikkløsning, hvor man kan hente ut statistikk som mest leste artikler, mest brukte nøkkelord/tags, antall sideoppslag osv Det skal være mulig å benytte seg av eksterne statistikkløsninger som Google Analytics Det skal være mulig å opprette sider som ikke synliggjøres i menystrukturen skjulte sider som nås med direkte adresseoppslag. 3

5 Det skal være mulig å merke innhold med tags/nøkkelord. Nøkkelordene skal generere en dynamisk tag cloud som kan synliggjøre aktualitetsstoff på nettsider Det skal være mulig å legge inn alias til en opprettet side Løsningen skal ha versjonskontroll av publisert informasjon, slik at man kan sammenligne flere versjoner av samme artikler, og eventuelt utføre rollback til tidligere versjoner. Nr. Krav Ja Må utvikles 4. Multimediafunksjonalitet Det skal være mulig å laste opp bilder i egne bildedatabaser. Opplastede bilder skal kunne merkes med bildetittel, fotograf, årstall/dato og annen relevant metadata Publiseringsverktøyet skal skalere bilder automatisk, slik at alle brukere slipper å forholde seg til pikselstørrelser Publiseringsverktøyet skal inneholde et bildearkiv/multimediearkiv for oppbevaring og strukturering av bilder der det er enkelt for alle redigerere å effektivt søke opp bilder og knytte disse til ulike deler av nettportalen Fil- og bildearkiv skal være tilgjengelig for alle redigerere i Rogaland fylkeskommune, skolene og andre virksomheter Linker til opplastede filer skal synliggjøres med ikon og filstørrelse (for eksempel PDF-ikon, navn på link, størrelse på fil) Det skal være mulig å sjekke om filene er i bruk eller ikke Løsningen skal støtte publisering av ferdigproduserte multimediefiler som for eksempel flash-filer og video på egne sider eller som sideelementer. (Se vedlegg 2, eksempel 3) Løsningen skal støtte publisering av ferdigproduserte html/javascript-presentasjoner som for eksempel AJAX og JQuery etc. på egne sider eller som sideelementer. (Se vedlegg 2, eksempel 3) Løsningen skal støtte og kunne opprette, publisere og redigere bildekaruseller på egne sider eller som sideelementer. Nei 5. Artikkeleditor Artikkeleditor skal støtte WYSIWYG editering Det skal være støtte for tidsstyring av artikler Det skal være funksjon for varsel til forfatter om artikler som nærmer seg utløpsdato Det skal være mulig å redigere i HTML-koden i maler og i artikler 4

6 5.5 - Det skal være enkelt å legge inn bilder og endre størrelsen på disse i artikler Det skal være mulig å forhåndsvise sider og artikler før publisering Det skal være mulig å automatisk tilpasse bildestørrelsen på ingressbilder slik at de følger en fastsatt bildestørrelse Det skal være mulig å automatisk tilpasse bildestørrelsen i artikler til maksimalt tillatt bildebredde Artikler og/eller artikkelfelter skal låses ved redigering, med mindre systemet støtter samtidig dokumentsamarbeid Artikler skal kunne krysspubliseres på flere sider i hele nettportalen Artikkel- og undersider skal fremstå med samme design og mal som den kategorien de publiseres i Det skal være mulig å velge om en artikkel skal ha en diskusjonstråd eller et skjema knyttet til seg eller ikke Kopiering fra andre filformater inn i Artikkeleditoren (for eksempel Microsoft Word) skal kunne formateres i løsningen Det skal være mulig å legge inn ekstra metadata som tema og status på enkelte artikler, slik at de kan kategorisere planer og prosjekter og tilgjengeliggjøre disse i egne søk. (Se vedlegg 2, eksempel 7 Planer og prosjekter) Løsningen skal støtte å angi tilgangsnivå på artikler som publiseres, slik at de kan skille mellom artikler som er interne for enkelte avdelinger/virksomheter og artikler som skal være tilgjengelige for alle som bruker intranettet Det skal være mulighet til å styre layouten på ulike sider. Her menes sidemaler for de ulike kategorisidene. For eksempel: Ansvarlig redaktør for utdanningssidene skal kunne styre layouten og velge fra sidemaler Alle filer og nettsider skal versjonshåndteres, og det skal være mulig å få en oversikt over hvem som har foretatt hvilke endringer på hvilke tidspunkt Alle intranettbrukere skal selv kunne publisere og redigere korte beskjeder i en felles oppslagstavle for sin virksomhet. Disse beskjedene skal fjernes automatisk fra sidene etter en gitt tidsperiode. (Se vedlegg 2, Eksempel 11, Viktig melding ) 5

7 6. Søkefunksjon Det skal tilrettelegges for enkel og avansert søk for alle brukere (både interne og eksterne) i artikler, dokumenter og personer. Søkefeltet skal være synlig på alle sider og være minimum 20 tegn langt Alle opplastede dokumenttyper skal være søkbare, slik at alle brukere (både interne og eksterne) skal kunne søke i hele nettstedet, inkludert alle dokumenter og vedlegg Alle brukere (både interne og eksterne) skal ha tilgang til en oppdatert oversikt ansattliste i organisasjonen til enhver tid Det skal gis en god presentasjon av søkeresultatet. På resultatsiden skal brukeren kunne begrense søket til enkelte innholdstyper og kategorier Det skal være mulig å søke etter personer/ansatte Søkeresultatene skal kunne sorteres etter relevans, alfabetisk og etter publiseringsdato. 7. Skjemaverktøy Det skal være mulig å opprette og vedlikeholde elektroniske skjema, slik at informasjon og tilbakemeldinger fra brukerne samles inn på en strukturert måte Alle innsendte data skal lagres i en database Autentiserte brukere skal ikke behøve å fylle inn brukerinformasjon på nytt Det skal være mulig å gi skjemaet navn, slik at det er enkelt å finne tilbake til det i løsningen Det skal være mulig å legge inn en eller flere e- postmottakere av innsendte data Det skal være mulig å opprette og redigere en bekreftelsestekst som vises etter at skjemaet er lagret Det skal være mulig å inaktivere og slette skjemaer Det skal være mulig å opprette, lagre og gjenbruke forhåndsdefinerte valglister for nedtrekkslister (for eksempel kommunenavn) Det skal være mulig å merke alle typer felter som er påkrevd Det skal være mulig å velge om skjemaet bare skal kunne sendes inn én gang per bruker Det skal være mulig å gjøre innsendte skjemadata offentlig tilgjengelige, og det må være mulig å velge hvilke felter som skal være med i denne visningen Skjemaverktøyet må støtte validering av felter, og forfatteren skal kunne velge valideringstype pr. felt (for eksempel personnummer og epost-adresse) Det skal være mulig å begrense hvilke forfattere som skal kunne redigere et skjema. 6

8 Skjemaverktøyet skal støtte følgende typer: o Enkel tekstlinje o Tekst over flere linjer o Dato / klokkeslett o Tall o Radioknapper o Avkrysningsfelt / flervalgslister o Nedtrekkslister o Filopplasting o Postnummer og poststed o Matriser (kolonnebasert input med dynamisk antall rader) Det skal være mulig å kopiere et skjema Det skal være mulig å eksportere skjemainnhold til regneark, samt videresending av datafangst på e- post (tekst, XML eller PDF). 8. Kurs og konferansefunksjonalitet Det skal i kurs- og konferansemodul være mulig å melde seg på både interne og eksterne arrangementer i fylkeskommunens regi. Ved påmelding skal det automatisk sendes tilbakemelding om at påmeldingen er mottatt Det må være mulig å foreta uttrekk av deltakerlister i eksempelvis Excel-format Det må være støtte for generering av deltakerlister, slik at en enkelt kan ha kontroll på hvem som er påmeldt til hvilket arrangement Det må være mulig å sende felles e-post til de påmeldte deltakerne på en enkel måte Både påmeldingsprosessen som helhet og hvert enkelt skjermbilde/tekst i prosessen må kunne redigeres av ansvarlig redaktør/administrator, slik at det er mulig å tilpasse løsningen til det enkelte arrangement, og slik at løsningen også kan brukes til andre former for forhåndsregistrering og bestilling Det må være mulig å begrense antall deltakere, slik at registrering av påmeldinger ikke er mulig ved oppnådd forhåndsdefinert antall Det må være mulig å kopiere et arrangement og bruke oppsettet til nye arrangement 9. Personalisert informasjon Intranett-brukere skal kunne redigere og oppdatere sin profil med kontaktinformasjon, interessefelt og/eller fagområder Intranett-brukere skal kunne abonnere på artikler og kalenderinnhold basert på sin profil. (Se vedlegg 2, eksempel 18) Intranett-brukere skal få en oversikt på intranettforsiden med informasjon som de abonnerer på. 7

9 9.4 - Intranett-brukere skal på en enkel måte kunne melde seg på interne kommende kurs og andre arrangement. (Se vedlegg 2, eksempel 11 og 18) 10. Prosjektrom Intranett-brukere skal kunne fylle ut et skjema der de søker om opprettelse av et prosjektrom. Redaktører skal få beskjed om søknaden som en melding i publiseringsgrensesnittet og enkelt kunne godkjenne søknaden Prosjektromeier skal selv kunne invitere interne og eksterne brukere til avgrensede prosjektrom på intranettet Prosjektrom-brukerne skal ha tilgang til en liste over alle interne og eksterne deltakere i prosjektrommet Prosjektrom-brukere skal kunne laste opp filer i en mappestruktur i prosjektrommet. Filene skal kunne deles med alle deltakerne av prosjektrommet Prosjektrom-brukere skal kunne legge ut meldinger og notater til de andre deltakerne i prosjektrommet Meldinger, notater og filer i prosjektrommet skal kunne kommenteres av deltakerne Det skal være mulig å lukke et prosjektrom og eksportere arkivverdige dokumenter og innhold, slik at brukere kan finne tilbake til informasjon fra avsluttede prosjekter. 11. Interaksjonsfunksjonalitet Det skal være støtte for spørreundersøkelser (polls). (Se eksempel 11 i vedlegg 2, Quiz) Det skal være støtte for nyhetsbrev. Leseren skal selv kunne melde seg på og melde seg av nyhetsbrev. Forfatterne skal kunne velge hvilke nyheter som skal sendes i nyhetsbrevet Det skal være støtte for diskusjonsforum. Det skal være mulig å legge til rette for diskusjonstråder i nyhetsartikler. Hvis noen har lagt ut et innlegg så skal et ikon som synliggjør dette vises på listningssiden (i tilknytning til ingressen). Det skal være mulig å autentisere brukere som vil lage innlegg, med validering mot e-post eller mot SMS Det skal være støtte for blogging Det skal være støtte for OSS/FAQ Det skal være støtte for enkel kobling mot sosiale medier. 8

10 12. Ansattliste Løsningen skal kunne presentere en ansattliste basert på import/integrasjon med fylkeskommunens kommunens AD/LDAP kataloger eller fylkeskommunens HRM system (Agresso) Ansattlisten skal kunne sorteres på avdeling. Utlisting pr avdeling skal kunne hentes frem med egne URLs Den enkelte ansatte skal ha sitt eget visittkort med navn, stillingstittel, avdelingstilhørighet, telefonnr og e-postadresse. Det skal være mulig å legge til bilde i visittkortet. Visittkortet skal ligge tilgjengelig på egne sider som da blir søkbart eksternt med navn og tittel Visittkortet skal støtte vcard slik at kontaktinformasjonen kan importeres i eksempelvis Outlook og/eller ical På artikkelsider med innholdsansvarlig/redaktør av innhold skal innholdsansvarlig fremkomme som en link på nyhetssiden. Denne linken skal føre til den enkeltes visittkort. Dette skal håndteres automatisk av løsningen. (Se eksempel 5, vedlegg 2 Standard artikkel) Teknologi og standarder Nr. Krav Ja Må utvikles Nei 13. Plattform Driftsansvarlig i fylkeskommunen skal kunne drifte løsningen på egne servere Systemet skal kunne kjøres på VmWare Systemet skal kunne kjøres på Windows 2008 R2 server eller SLES (Suse Linux Enterprise Server av nyere dato) Det skal være mulighet for full websupport 14. Integrasjon Intranettet skal være tilgjengelig fra internett i brukerens nettleser når man logger inn via Rogaland fylkeskommunes Novell Access Manager-portal Det skal være mulig å opprette passordbeskyttede sider. Løsningen skal støtte autentisering via FEIDEintegrasjon og AD/LDAP, for autentisering mot Novell edirectory og for uttrekk av informasjon (for eksempel en ansattliste) Løsningen skal kunne liste ut informasjon fra eksterne feeds, for eksempel RSS-kanaler Løsningen skal kunne liste ut informasjon fra eksterne datakilder, for eksempel tilgjengelig som XML. 9

11 Nettportalen skal kunne sikres med sertifikat og kjøres som Løsningen skal støtte portlets, slik at kommunen kan utvikle elektroniske tjenester/funksjonalitet og sømløst implementere dette på hjemmesiden. Nr. Krav Ja Må utvikles 15. Søkemotoroptimalisering Malverket skal validere 100 % mot W3C XHTML sine standarder Malverket skal validere 100 % mot W3C CSS validatoren Alle menyer skal være tekstbaserte (ikke basert på eksempelvis flash eller javaskript) Alle hovedoverskrifter skal kodes med H Sidens tittel skal kodes med TITLE tag. Hver side skal påføres unike tags. Sidens TITLE tag skal settes lik artikkelens overskrift (TITLE = H1) Meta Keywords og Meta Description skal kunne påføres hver enkelt side. Meta Descriptions skal alltid kunne overstyres i løsningen Det skal være mulig å sperre for søk på sider som ikke ønskes gjennomsøkt ALT-atributten på bilder skal påføres automatisk ved at den skal speile filnavnet. TITLE skal settes automatisk lik ALT. Det skal være mulig å endre på dette manuelt om ønskelig Det skal ligge en sitemap.xml på rotnivå som speiler innholdsstrukturen. Denne skal oppdatere seg automatisk dersom forfattere oppretter og sletter sider Hjemmesiden skal kunne leses av alle nettlesere med versjonsnumre som har vært på markedet de siste par årene (IE, Firefox, Chrome, Opera, Safari osv) Løsningen skal ha en URL-struktur som er søkemotorvennlig. Det må ikke benyttes session ID i URLene Bruk av inline style og inline javaskript skal ikke forekomme Ingen URLs skal være duplikate med tanke på innhold Det skal aldri være mindre enn 5 % forskjell i den heksadesimale fontfargen og bakgrunnsfargen på siden Spesialtegn og landsspesifikke tegn skal kodes rett i Character Entities i henhold til valgt standard Hjemmesiden skal ikke benytte rammer (frames) Alle sidene skal ha meningsbærende og leservennlige adresser (URLs). Nei 10

12 Nettløsningen skal være korrekt kodet i henhold til gjeldende standarder Implementering og drift Nr. Krav Ja Må utvikles 16. Dokumentasjon Leverandøren skal beskrive sikkerhetsløsninger innebygd i løsningen samt eventuelt anbefalinger om tilleggssikring via tredjepartsprodukter (sertifikater eller annet). Dette gjelder både innholdssikkerhet og sikkerhet knyttet til administrasjon av løsningen Leverandøren skal levere elektroniske brukerhåndbøker for løsningen. 17. Opplæring Leverandør skal tilby egnet opplæring av nettportalen og beskrive og prisfeste opplæringsbehovet for brukergruppene: Nei o Administratorer i sentraladministrasjonen - minimum 5 personer o Ansvarlige redaktører i sentraladministrasjonen - minimum 12 personer o Ansvarlige redaktører på skolene (3 pilotskoler) minimum 8 personer Tallene er retningsgivende og ikke forpliktende. Pris oppgis i prisskjemaet Opplæring i nye versjoner skal skje etter behov. Leverandør skal ha møte med oppdragsgiver en gang per år gjennom brukerforum eller andre organiseringer. 18. Demo Demo av publiseringsverktøyet ønskes vedlagt for å visualisere ønsket funksjonalitet og brukervennlighet 19. Videreutvikling Rogaland fylkeskommune skal ha tilgang til siste versjon ved videreutvikling av systemet uten å forhandle på nytt Dersom de andre videregående skolene, utenom de 3 pilotskolene, ønsker å ta løsningen i bruk, skal dette kunne gjøres uten å forhandle på nytt. 20. Support - Leverandøren skal ha et tilgjengelig supportapparat innenfor normal arbeidstid, og definere sin responstid knyttet til innmeldte saker. 11

13 E-håndbok (Opsjon) Nr. Krav Ja Må utvikles 1. Funksjonalitet Nei Det skal ikke kreves ekstra innlogging eller passord for tilgang til e-håndboken for intranettbrukere som alt er innlogget i fylkeskommunens system. (SingleSignOn) Systemet skal gi tilgang til oppdaterte lover, forskrifter o. l. Det skal være mulig å opprette interne og eksterne lenker til overordnede lover og forskrifter og til andre dokumenter som bl.a. finnes i oppdragsgivers Sak- og arkivsystem (EDB Sak og arkiv) Det skal være mulig å oppdatere hele eller deler av dokumenter fortløpende Alle dokumenttyper skal være søkbare, slik at intranettbruker kan søke i hele nettstedet, inkludert alle dokumenter og vedlegg Systemet skal varsle forfatter om tid for revisjon Dokumentene skal inneholde opplysninger om når siste revisjon var foretatt Det skal ikke være tidsbegrensning for revisjonsdato fram i tid En skal kunne lese dokumentene som websider, slik at brukeren er software-uavhengig Det skal være mulighet for å legge inn bilder, videofiler etc. i et dokument Bruker skal alltid ha den nyeste dokumentversjonen tilgjengelig, og den opprinnelige lenken skal ikke endres selv om dokumentet redigeres Det skal være støtte for å knytte sammen relaterte dokumenter i e-håndboka. Slik at vi kan lage referanser og samlinger med dokumenter Det skal være støtte for å velge om dokumentet skal kunne lastes ned eller kun vises som webside, for å unngå at brukerne laster ned en versjon som tilgjengeliggjøres via andre kanaler 12

14 Nr. Opplæring Ja Må utvikles 2. Opplæring Dersom e-håndbok blir levert av samme leverandør som ny nettportal skal leverandør tilby egnet opplæring av e-håndboken og beskrive og prisfeste opplæringsbehovet for brukergruppene: Nei o Administratorer i sentraladministrasjonen - minimum 5 personer o Ansvarlige redaktører i sentraladministrasjonen - minimum 15 personer o Ansvarlige redaktører på skolene (3 pilotskoler) minimum 20 personer Tallene er retningsgivende og ikke forpliktende. Pris oppgis i prisskjemaet Opplæring i nye versjoner skal skje etter behov. Leverandør skal ha møte med oppdragsgiver en gang per år gjennom brukerforum eller andre organiseringer. 13