Kravspesifikasjon. Alle punkt i kravsmatrisene må fylles ut av tilbyder. Kolonnene betyr som følger:

Transkript

1 Vedlegg 1: Kravspesifikasjon for Publiseringsverktøy (MS) og webdesign for Norges Musikkorps Forbund Kravspesifikasjon Det er viktig at tilbyderne synliggjør hvordan de vil sikre høy kvalitet både i prosjektet og i leveransen. Vi vil gjerne se referanser til nettsider med løsningene som tilbys. Disse kan omtales i kommentarfeltet eller med henvisning til eget vedlegg. Der vi ber om beskrivelser, ønsker vi at de er korte, og at det går tydelig frem hvis noe i kravet ikke kan tilbys. lle punkt i kravsmatrisene må fylles ut av tilbyder. Kolonnene betyr som følger: Krav til leverandør: Oppdragsgivers krav til leverandør/leveransen. Svar (J/N): J = Ja, dette er inkludert i tilbudet/vi aksepterer kravet. Gi evt. utfyllende kommentar. Hvis det finnes mange ulike alternativer for å imøtekomme kravet, skal leverandøren foreslå det beste alternativet. N = Nei, dette er ikke inkludert/vi aksepterer ikke kravet. Gi utfyllende kommentar. Utfyllende kommentar kreves: Når det er merket «x» i kolonnen for utfyllende kommentar kreves, må leverandør gi en kort beskrivelse av sitt løsningsforslag til det tilhørende kravet. Utfyllende kommentar: Her angis utfyllende kommentar eller referanse til hvor i tilbudet kommentaren er gitt, for eksempel sidetall, punkt, vedlegg. Utfyllende kommentar kan gis av leverandør på alle punkt om ønskelig, men er bare påkrevd der "Utfyllende kommentar kreves" er merket med. Utfyllende kommentar kan også gis i vedlegg 2 og merkes med nr. (f.eks. 1.4) og skal sorteres i stigende nummerrekkefølge. I "Utfyllende kommentar" skriver man da f.eks.: "Se vedlegg 2 pkt. 1.4" Kravtype/prioritet: Oppdragsgivers krav er kategorisert i, og -krav. Disse har følgende prioritet: -krav er absolutte minstekrav som leverandør må oppfylle. Oppfylles ikke -krav vil tilbudet avvises. Ved å besvare et -krav med J forplikter leverandør seg til å kunne oppfylle det aktuelle kravet. -krav er krav med høy viktighet for oppdragsgiver. -krav er mindre viktige enn -krav, men fortsatt viktige.

2 1 Generelle krav til prosjekt og leveranse Nr Krav til Leverandør Svar fra leverandør (J/N) Utfyllende kommentar kreves Utfyllende kommentar (fylles ut av leverandør) Kravtype 1.1 Leverandøren må vise til 3-5 responsive nettsteder som leverandøren har utviklet, og oppgi referanser/kontaktdetaljer til kunde. 1.2 Leverandøren må på forespørsel tillate ekstern kvalitetssikring av alle forhold som er relevante for leveransen. 1.3 Leverandør skal ha hovedansvar for testing underveis, og må rette opp eventuelle svakheter ved interaksjonsdesign og grafisk design etter testingen. Oppdragsgiver kan bistå med testing etter nærmere avtale. 1.4 Norsk brukerveiledning i utskriftsversjon og digital utgave (utarbeides for administratorer og brukere når systemet er klart for innholdspublisering). 1.5 Leverandøren må bidra med opplæring, på norsk, til oppdragsgiver. Leverandøren bes beskrive hvordan opplæring av oppdragsgivers personell vil gjennomføres. 2

3 1.6 Leverandøren skal i eget bilag gi en oversiktlig, kortfattet beskrivelse av hvordan leverandøren tilnærmer seg oppdraget, inkl. funksjonalitet og prosjektplan med milepæler og delleveranser. 1.7 Leveringsdag for nye nettsider basert på ferdig oppsatt publiseringssystem skal være senest 1. desember Leverandøren bes beskrive kompetansen til navngitt personell som vil være involvert i prosjektet og vedlegge Ver med personenes kvalifikasjoner og tre mest relevante oppdrag, inkl. kontaktinformasjon til referansepersoner. 1.9 Leverandøren skal kort beskrive sin erfaring og kompetanse med verktøy som inngår i løsningen (MS, søkeverktøy etc.) 1.10 Leverandøren bes beskrive sine rutiner for kvalitetssikring av leveransen Leverandøren skal ha ansvar for at eventuelle underleverandører har samme kvalitetssikring som leverandør Testmiljøet for de tekniske løsningene skal ligge hos leverandøren. Leverandør bes beskrive testaktivitetene som inngår i leveran- 3

4 sen Leverandør skal ha ansvar for å teste at alt fungerer på alle de vanligste enheter, operativsystem og nettlesere. 2 Krav til brukervennlighet og universell utforming Nr Krav til Leverandør Svar fra leverandør (J/N) 2.1 Tilgjengelighet og universell utforming Webløsningen skal oppfylle kravene til tilgjengelighet for personer med nedsatt funksjonsevne som gjelder for de viktigste hovedpunktene i Diskriminerings- og tilgjengelighetsloven. I utgangspunktet betyr det at nettstedet bør følge de internasjonale retningslinjene WG 2.0 (Web ontent ccessibility Guidelines) nivå, spesifisert av Difi: -til-nettlosninger/krav-wcag Tilgjengelighetskravene skal være styrende både for utformingen av løsningen, og deretter for den tekniske konstruksjonen. åde designere og utviklere må være kjent Utfyllende kommentar kreves Utfyllende kommentar (fylles ut av leverandør) Kravtype 4

5 med og forstå disse kravene ll funksjonalitet på nettstedet og publiseringssystemet skal kunne brukes uten at sluttbrukere eller administratorer må laste ned annen programvare enn standard nettleser Det skal ikke brukes Flash, Java eller tilsvarende teknologier. ll funksjonalitet må kunne brukes selv om script, applets eller andre programmerte objekter er avslått eller ikke støttes. 2.2 Webdesign og responsivt nettsted Leverandøren skal lage oppsett over informasjonsarkitekturen Leverandøren skal levere grovskisser/mockups og godta minimum 2 revisjoner fra kunden Leverandøren skal levere ferdigskisser som html og godta minimum 2 revisjoner fra kunden Nettsidene må være responsive med design som er flytende og automatisk tilpasser seg alle typer enheter med nettlesere 5

6 (slik som pc, smarttv, smarttelefoner og nettbrett), både i stående og liggende posisjon Nettstedet skal både kunne redigeres og leses med Internet Explorer 9 og nyere, samt Firefox, hrome, Safari og tre siste versjoner av disse Nettstedet skal bruke HTML5 og SS3. 3 Funksjonelle krav Nr Krav til Leverandør Svar fra leverandør (J/N) Utfyllende kommentar kreves Utfyllende kommentar (fylles ut av leverandør) Kravtype 3.1 Generelle krav til publiseringsverktøyet Løsningen må fremstå som én løsning med én og samme innlogging, uavhengig av om den består av flere delkomponenter ll publisering må kunne gjennomføres uten at skribentene har kjennskap til HTML HTML-koden for innholdet må være tilgjengelig og redigerbar Løsningen må ha en funksjon for å dele artikler og annet innhold til e-post og ut- 6

7 valgte sosiale medier Løsningen skal være lokalisert for norske forhold. Eks.: Norsk alfabet skal følges (æ, ø, å/aa til slutt i lister), ET tidsregning 24 t norsk tidssone, ukestart mandag Det skal være enkelt å administrere brukertilganger. MS-løsningen skal ha egendefinerte rollekategorier for tilgang, redigering og publisering. Vi ønsker selv å styre antall bidragsytere, redaktører og systemadministratorer, og vil selv ta hånd om tilgangskontrollen. Det må kunne defineres spesifikt hvilke funksjoner hver rolle skal ha tilgang til å redigere rbeidsflyt: lt innhold må kunne lagres som kladd, sendes til godkjenning, publiseres, avpubliseres og slettes. Redaktører/administrator skal kunne godkjenne og publisere andres artikler/objekter når de er sendt til godkjenning lt som opprettes skal ha en eier. ndre skal kunne redigere publisert innhold selv om de ikke står som eier. Eier skal ikke være synlig for publikum. 7

8 3.1.9 Nettstedet skal kunne tilby RSS-strømmer fra nyheter og evt. arrangementer Utlistinger skal kunne sorteres valgfritt etter publiseringsdato eller alfabetisk, og kunne overstyres manuelt (prioritert rekkefølge) Lange lister skal kunne deles opp og vises i et hensiktsmessig antall sider. Det skal være mulig å navigere mellom sidene dministrasjonsgrensesnittet bør også være responsivt Det bør være mulighet for å sette opp enkle skjemaer med epostkvittering til bruker og varsel til redaktør Systemet skal ha en arrangementskalender, med tidsrom, sted, arrangør, adresse, kart og andre relevante data. Kalenderen skal også støtte gjentagende hendelser (recurring events). 4 Maler og innleggstyper 4.0 Leverandør skal utvikle alle de maler og innholdstyper som løsningen krever. Vi er åpne for forslag til hvordan dette kan løses. 8

9 4.1 Innleggsredigering (editor) Publiseringsverktøyet må inneholde de vanligste tekstredigeringsfunksjonene, (minimum klipp ut, kopier, lim inn, fet skrift, kursiv, punktlister, nummererte lister, lenke, overskrifter) Systemet må støtte forhåndsvisning før publisering Når tekst limes inn skal tekstformateringer kunne fjernes (eks. koder fra Word) Det skal være mulig å bruke anker i brødtekst Forfattere (byline), kontaktpersoner og tilknyttede personer på nettsidene skal vises som lenke til personside Eldre versjoner av innlegg bør kunne lagres og versjoner kunne håndteres Slettede innlegg skal ligge i en papirkurv eller lignende, og kan gjenopprettes i løpet av en gitt tid etter sletting Redaktør skal selv kunne velge om innlegget skal inneholde overskrift, ingress, brødtekst, eller om enkelte av disse ikke ønskes 9

10 benyttet i det enkelte tilfellet Løsningen må inneholde en funksjon for tidsstyrt både publisering og avpublisering på dato og klokkeslett. 4.2 Språk Det skal være mulig å oversette utvalgte sider eller innlegg til andre språk. Når det finnes en versjon på et annet språk, skal dette tydelig fremgå på siden Det skal kunne genereres et eget nettsidekart for hvert enkelt språk Det skal være lettvint å oversette og administrere oversettelser rukere bør kunne gå direkte fra norsk til fremmedspråklig artikkel og motsatt ved kun ett klikk, så sant samme artikkel er oversatt. 4.3 ilder Det må finnes et bildearkiv som kan brukes overalt i løsningen, på alle språk lt-tekst og bildebeskrivelse med evt. stikkord skal kunne legges til på bilder. 10

11 4.3.3 Systemet skal automatiske lage skalerte bilder etter definerte størrelser som samsvarer med maler og kriterier for responsivt design ilder skal også kunne beskjæres manuelt lle de vanligste bildeformatene skal kunne brukes, inkl. format for infografikk For å fjerne særtegn (æ, ø, å) bør filnavn kunne gis nytt navn når bilder lastes opp Samme bilde må kunne brukes i flere sammenhenger med ulik bildetekst. ildeteksten må knyttes til artikkelen/ sammenhengen den opptrer i Vi ønsker at det skal være mulig å kunne velge flere alternative plasseringer av bilder uten å bli låst av systemet, sett inn til høyre på siden, sett inn til venstre på siden osv. i innlegg Det skal være mulig å ha bildeserier på utvalgte sider. ildene som tilknyttes saken legger seg da automatisk i en bildeslide med bildetekst. Det skal være mulig å bla mellom de ulike bildene. ildeserien kan vises med et hovedbilde, mens resten av bildene i serien ligger under i miniatyr. Det 11

12 skal også være mulig å klikke på bildene og få opp store bilder. ildetittel, fotograf og annen relevant informasjon skal fremkomme i tilknytning til de enkelte bildene Innholdet i mediaarkivet må ikke være indeksert og tilgjengelige på nettsidene uten at de er tilknyttet en innholdstype. Mediaarkivet må altså kunne inneholde bilder og filer som ikke er søkbare, synlig eller tilgjengelig før de er publisert på en innholdsside. 4.4 Navigasjon og arkitektur Det må være enkelt for brukerne av nettstedet å navigere på sidene Global meny må være tilgjengelig på alle nettsider Vi ønsker automatisk generering av navigasjonssti/brødsmulesti med bruk av titler. Stien skal være klikkbar på alle nivåer Navigasjon skal være tekstbaserte linker, ikke utvikles i java/flash el.l Redaktør skal selv kunne opprettes det antall menypunkter strukturen som opp- 12

13 dragsgiver selv ønsker, uten begrensninger i systemet Redaktør skal kunne opprette, endre, slette og flytte menypunkter, og prioritere rekkefølge på menypunkter Nettstedet skal ha en klikkbar oversikt over innholdet. Nettstedskartet skal genereres automatisk når noe endres I tillegg til nettstedskart skal det være en -Å-liste over sidene på nettstedet. 4.5 Søkefunksjon Søkefunksjonen må være god og omfatte: - fritekstsøk i alt innhold på hele nettstedetm inkludert metadata - søk i tekst i pdf-filer og andre dokumenter Det skal være mulig for sluttbruker å avgrense søkeresultater Ved søk med to ord bør søkeresultatet først vise sider som har begge søkeordene Det bør være mulig å autofullføre søkeord lt innhold må være søkbart for innlogget redaktør, inkludert upublisert innhold. 13

14 4.6 Søkemotoroptimalisering Leverandør skal gi en kort beskrivelse av hvordan best mulig søkemotoroptimalisering for musikkorps.no vil sikres Publiseringssystemet skal leveres med søkemotoroptimaliserte maler som standard Nettstedet skal ha beskrivende sidetitler og adresser. Title og overskrift må være helt like, overskrifter må kodes med h1, h2, h Det genereres automatisk brukervennlige/tekstbaserte webadresser i henhold til navnet på den opprettede siden. Det skal også være mulig å lage URLer selv Løsningen skal ha mulighet for metadata for description og keywords på alle sider, og disse skal kunne genereres automatisk Det bør ikke benyttes teknologier som forhindrer normal indeksering Løsningen bør ha en sitemap.xml-fil på rotnivå, og denne bør oppdateres automatisk Publiseringsverktøyet bør varsle når inter- 14

15 4.7 Nøkkelord ne lenker er brutte eller døde Nøkkelord skal skrives automatisk til meta keywords. 4.8 Filarkiv MS-løsningen må ha integrert filarkiv for administrasjon av filvedlegg og bilder De som publiserer må ha mulighet til å søke i alle bilder og filer, både på filnavn og nøkkelord som er lagt til Det bør finnes en oversikt over hvor enkelte bilder og filer er brukt på nettstedet, og en oversikt over relasjoner mellom artikler og sider. 5 Tekniske krav Nr Krav til Leverandør Svar (J/N) Utfyllende kommentar kreves 5.1 Teknologi, systemkrav og ytelse Nettstedet må være optimalisert for god ytelse og rask nedlasting. Utfyllende kommentar (fylles ut av leverandør) Kravtype 15

16 5.1.2 Leverandør skal spesifisere hvilke anbefalinger eller krav som stilles til server og programvare som løsningen skal kjøre på om NMF velger å hoste og drifte selv Løsningen bør baseres på åpen kildekode. 5.2 Integrasjon av multimediefiler og deletjenester ilder og videoklipp fra andre nettsteder, som eksempelvis Flickr, Vimeo og YouTube, må enkelt kunne settes inn i innlegg. 6 Drift, støtte og vedlikehold av løsningen Nr Krav til Leverandør Svar (J/N) Utfyllende kommentar kreves Utfyllende kommentar (fylles ut av leverandør) Kravtype 6.1 Løsningen skal som opsjon kunne installeres på server hos leverandør. Dette prises separat. eskriv den tekniske løsningen dere tilbyr. 6.2 Leverandør skal som opsjon vedlikeholde server og operativsystem, og besørge backup, feilretting og support. Dette prises separat for år 1 og år Leverandør bes redegjøre kort for sitt tilbud innen brukerstøtte og support. 16

17 6.4 rukerstøtte skal ytes i form av telefonsupport, e-post og/eller via en nettside, med kort responstid. Leverandør skal foreslå passende Service Level greement. 6.5 rukerstøtte og opplæring skal kunne gis på norsk. 17