KUNDENS KRAVSPESIFIKASJON FOR ANSKAFFELSE AV ELEKTRONISK REKRUTTERINGSVERKTØY

Transkript

1 KUNDENS KRAVSPESIFIKASJON FOR ANSKAFFELSE AV ELEKTRONISK REKRUTTERINGSVERKTØY Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 1 av 35

2 Innhold 1. Bakgrunn for anskaffelsen Formål og målbildet Overordnede mål Effektmål/gevinster Resultatmål Omfang (avtalens punkt 1.1) Opsjoner til leveransen Forutsetninger Avgrensinger Dagens situasjon Dagens arbeidsprosesser Dagens arbeidsrutiner Veiledning til dokumentet Ordliste Vedlegg Besvarelse av kravspesifikasjonen Anskaffelsens innhold Kundens kravtabeller Kravtabell oppbygging Leverandørens besvarelse Strukturering av Leverandørens besvarelse Behovsbeskrivelse Overordnet om løsningen Omfang (Scope) Omgivelse (Kontekst) Interessenter Forutsetninger Funksjonell kravtabell Kvalitetskrav Om appendix A Krav til integrasjoner Endringer/oppgraderinger Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 2 av 35

3 4.4. Produktspesifikt Andre ytelser og øvrige leveranseelementer Generelt Tilpasninger og installasjon mv (avtalens punkt 2.1.2) Bistand Dokumentasjon og opplæring (avtalens punkt 2.1.4) Undersøkelsesplikt (avtalens punkt 2.2.2) Testmiljø Utfylling av avtalebilag Eksterne rettslige krav (avtalens punkt 2.7) Fri programvare (avtalens punkt 4.3) Support Ytelsesnivå i garantiperioden SLA Appendix A - Kvalitetskrav Ytelse og robusthet Integrasjon, IT-arkitektur og plattform Sikkerhet Tilganger Dokumentasjon Juridiske krav Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 3 av 35

4 1. BAKGRUNN FOR ANSKAFFELSEN Dette dokumentet med vedlegg inneholder Kundens krav til programvare som skal inngå i bilag 1 til den endelige avtalen. Leverandøren skal på bakgrunn av denne beskrive sin løsning i bilag 2 til den endelige avtalen Formål og målbildet Formålet med anskaffelsen er å inngå ny avtale om bruk av elektronisk rekrutteringsverktøy. Rekrutteringsverktøyet skal benyttes til rekrutteringer til stillinger hos Kunden. I dag utfører Kunden ca rekrutteringer i året Overordnede mål Kunden ønsker å oppnå følgende overordnede mål med anskaffelsen. Likebehandling av alle søkere til ledige stillinger hos Kunden Sikker behandling av personalopplysninger Søkerne oppfatter Kunden som en profesjonell arbeidsgiver En systematisk innsamling og bearbeiding av alle relevante data ifm en rekrutteringsprosess Forenklet samarbeid mellom ledere og HR God arbeidsstøtte og flyt i rekrutteringsprosessen God dokument- og informasjonsflyt undervegs i rekrutteringsprosessen God oversikt over rekrutteringsbehovet Forskriftsmessig rekruttering Enkle og tilgjengelige rapporter og liste Et verktøy for analyse av kanaler, kostnader og andre relevante opplysninger som er lagt inn av søker/kunde ifm en rekrutteringsprosess Effektmål/gevinster Kunden ønsker å hente ut følgende gevinster med anskaffelsen: Effektivisere prosesser innen rekruttering både for interne og eksterne brukere ved å o redusere antall bilder/fliker og antall klikk for de ulike brukergruppene o samle funksjonalitet som hører naturlig sammen i samme bilde o kopiere tidligere rekrutteringer prosjekter for gjenbruk o ha mulighet for automatisk mellomlagring av søknadsutkast (for søker) o alle interne brukere får oppstartsbilde med oversikt over "mine rekrutteringsprosjekter" o ha tilgang til rekrutteringsverktøyet på ulike plattformer som PC, Mobil, nettbrett Et tidsriktig rekrutteringssystem som er intuitivt og lett å bruke for eksempel ved bla. standardisert symbolbruk, mulighet for bruk av filmsnutter etc. Mulighet til å måle antall avbrutte søknadsregistreringer Mulighet for justering av søknadsskjema for hver prosess Økt fleksibilitet for rekrutterer mht å definere obligatorisk informasjon for søker Økte analysemuligheter mht kanaler, kostander, innsamlede data for eksempel utdannelsesgrad, demografiske-data (bosted, alder, kjønn), antall rekrutteringer pr divisjon, avdeling, leder Effektiv overføring av arkivverdige opplysninger Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 4 av 35

5 Resultatmål Kunden ønsker å oppnå følgende resultater med anskaffelsen: Ny avtale om elektronisk rekrutteringssystem Elektronisk rekrutteringsverktøy er klar til bruk til avtalt tid ihht kontrakt Omfang (avtalens punkt 1.1) Anskaffelsen omfatter leveranse av følgende: elektronisk rekrutteringsverktøy som en multiplattform og multikanaltjeneste portablecv import/opplasting mailforsendelse multi-branding (ulike firmaprofiler med ulik logo, farger, skrift etc) (opsjon) integrasjon med relevante publiseringskanaler for stillingsannonser integrasjon med LinkedIN integrasjon med Kundens skybaserte autentiseringsløsning (Azure skybasert brukerkatalog (Active Directory)) integrasjon med Kundens arkivsystem (Acos WebSak) (opsjon) integrasjon med ID-porten for pålogging (autentisering) for eksterne brukere (søkere) (opsjon) dokumentasjon av løsningen bistand til å sette opp løsningen samt systemtilpasninger helhetstest-miljø for SaaS leveransen (som er mest mulig prodlikt) produksjonsmiljø for SaaS leveransen 1.4. Opsjoner til leveransen Anskaffelsen har følgende opsjoner som bør prises separat i tilbudet: Integrasjon med eksterne systemer som er angitt i kapittel 1.3 Opplæring utover en opplæringsgrunnpakke Vedlikehold og drift av løsningen Forutsetninger Følgende forutsetninger er lagt til grunn for anskaffelsen: Leveransen av elektronisk rekrutteringsverktøy er klar til begrenset bruk (pilot) i produksjon senest innen Det inngås SLA-avtale mellom Kunde og Leverandør Driftsavtale baseres på SSA-D Eventuell vedlikeholdsavtale hhv. SSA-V eller innbakes i SSA-D Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 5 av 35

6 1.6. Avgrensinger Anskaffelsen omfatter ikke fysisk utstyr (maskinvare) Dagens situasjon Dagens arbeidsprosesser Dagens rekrutteringsprosess omfatter følgende arbeidsprosesser: 1. Ekstern søknadsprosess potensielle søkere til stillinger hos Kunden 2. Interne arbeidsprosesser hos Kunden: o Utlysning o Utvelgelse o Tilsetting o Avslutning Figuren nedenfor illustrerer overordnede arbeidsprosesser som inngår i dagens rekrutteringsprosess. Utlysning Søknad Utvelgelse Tilsetting Avslutning Beskrivelse av figur 1: Figur 1 Overordnede arbeidsprosesser Interne prosesser er farget orange og ekstern prosess er faget grønn. Rutiner som inngår i den enkelte arbeidsprosess er nærmere beskrevet under dagens arbeidsrutiner kapittel Forretningsregler: Kunden er offentlig institusjon som er underlagt lovpålagte krav mht offentlig- og utvidet søkerliste Dagens arbeidsrutiner Generelt Dagens rekrutteringsprosess utføres ihht gjeldende lovverk og særavtaler. HR administrer rekrutteringsprosessene, lederne og rekrutteringsteamet har tilgang til søknadene. Utlysning Dagens utlysningsrutiner består av følgende trinn: Leder som har ledig stilling utarbeider en stillingsspesifikasjon/oppgavebeskrivelse i samarbeid med HR. HR utformer utlysning på bakgrunn av stillingsspesifikasjonen. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 6 av 35

7 HR publiserer stillingsannonsen til aktuelle kanaler (finn.no, ). HR utformer utvidet søkerliste når søknadsfrist er ute. HR utformer offentlig søkerliste sendes ut til de som er part i saken og som ber om innsyn. Listen sendes ut pr post til eksterne interessenter. I fremtiden må listen kunne sendes ut elektronisk på en sikker måte. Utvelgelse Dagens utvelgelsesrutiner består av følgende trinn: Leder mottar og leser søknader (evt. med bistand fra rekrutteringsteamet) Leder velger ut og prioriterer relevante søkere i samarbeid med HR Leder har ansvar for å invitere og gjennomføre 1. og 2. g intervju Leder ringer referanser Leder prioriterer søkerne Leder lager forslag til innstilling Innstillingsrådet behandler forslag til innstilling Tilsetting Dagens tilsettingsrutiner består av følgende trinn: HR utformer, sender ut og arkiverer tilbud om tilsetting til innstilt kandidat direkte i Kundens arkivsystem (Acos WebSak arkiv) Kandidat returnerer signert ansettelseskontrakt som arkiveres Avslutning Dagens avslutningsrutiner består av følgende trinn: HR arkiverer signert ansettelseskontrakt direkte i Kundens arkivsystem (Acos WebSak arkiv), på spesielt HR område med begrenset tilgang. HR oppdaterer informasjon om nyansatt i rekrutteringsløsningen HR og leder evaluerer rekrutteringsprosess treffsikkerhet i utlysning, tidsbruk, kostnadsbruk HR arkiverer dokumenter i rekrutteringsprosessen for eksempel søkerlister 1.8. Veiledning til dokumentet Kapittel 1 inneholder en overordnet informasjon om anskaffelsen. Kapittel 2 gir praktisk og konkret informasjon om Leverandørens besvarelse og Kundens forventninger vedrørende denne. Kapittel 1 og 2 er ment å danne et bakteppe for lesingen av resten av dokumentet. De to første kapitlene inneholder ikke formuleringer av spesifikke krav eller behov som forutsettes kommentert eksplisitt av Leverandør. Kapittelet er ment å bidra til forståelsen av Kundens behov. Kapittel 3, 4, 5 og 6 utgjør kjernen i kravspesifikasjonen knyttet til anskaffelsen. Eventuelle utviklingsbehov som danner grunnlag for opsjoner i avtalen er også omtalt her. Kapittel 4 inneholder noen kvalitetskrav/ ikkefunksjonelle krav samt henvisning til Kapittel 6 - appendix A som inneholder flere kvalitetskrav. I kapittel 5 omtales krav andre ytelser og leveranseelementer som er knyttet til anskaffelsen, for eksempel krav til support og opplæring. Kapittel 6 er appendix A som inneholder de fleste kvalitetskravene. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 7 av 35

8 Begreper og forkortelser som ikke antas å være allment kjent, er forklart i kapittel 1.9. Oversikt over underbilag/vedlegg til dette dokumentet er listet opp i kapittel Ordliste Tabellen nedenfor inneholder spesielle ord, begreper og forkortelser som er benyttet i dokumentet. Ord, Begrep, utrykk Søker Kvalitetskrav SLA Rådsmedlem Godkjenningsprøve Forklaring Jobb-søker Ikke-funksjonelle krav Service Level Agreement, Driftsavtale Person som er medlem av innstillingsrådet. Begrepet brukes i avtalen. I denne avtalen benyttes begrepet godkjenningsprøve om kundens test av standard programvare. Akseptansetest Helhetstest Godkjenningsperiode Helhetstest-miljø Systemet AD I denne avtalen benyttes begrepet akseptansetest om Kundes test av kundetilpasninger i programvaren. Omfatter Kundens test av både standard programvare (godkjenningsprøve) og kundetilpasninger (akseptansetest) Tidsbegrenset periode som løper fra kundetilpasninger er akseptansetestet ok, akseptansetestet er godkjent og kundetilpasninger er installert i produksjon Testmiljø hvor kunden kan utføre godkjenningsprøve, akseptansetest og helhetstest av løsningen Benyttes om elektronisk rekrutteringsverktøy Active Directory Vedlegg Oversikt over vedlagte dokumenter som også er en del av Kundens kravspesifikasjon. Vedlegg 1: Forskningsrådets digitaliseringsstrategi (Kortversjon).pdf Vedlegg 2: Forskningsrådets IKT-arkitektur (fullversjon, vedtatt 2008, oppdatert høsten 2014).pdf Vedlegg 3: Retningslinjer, en god brukeropplevelse.pdf Vedlegg 4: Preferert plattform, støttesystem, IT-system i Forskningsrådet (oppdatert høsten 2014).pdf Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 8 av 35

9 2. BESVARELSE AV KRAVSPESIFIKASJONEN Nedenfor følger konkretisering av hvilke elementer anskaffelsen består av, samt veiledning om Kundens kravtabell og retningslinjer vedrørende Leverandørens besvarelse på denne behovs- og kravspesifikasjonen Anskaffelsens innhold Kunden ønsker gjennom denne forespørselen å motta prisede tilbud på følgende: Elektronisk rekrutteringsverktøy Opsjoner, se kapittel 1.4. Eventuelle lisenskostnader 2.2. Kundens kravtabeller Etterfølgende kapitler, appendix og underbilag inneholder Kundens kravspesifikasjon. Hvert kapittel inneholder detaljerte krav spesifisert i kravtabell. Kravene beskriver den bistand Leverandør skal yte med implementering og tilpasning av den programvare som er levert. Et eksempel på kravtabell er gitt i tabellen nedenfor: Krav Prioritet (prio.) Kravtekst, beskrivelse Svar-kode 7 Krav som skal være testbar når løsningen er implementert Leverandøren bes å beskrive løsningen Kravtabell oppbygging Hver kravtabell tilhører et kapittel og underkapittel som står foran hvert krav nummer selv om dette ikke er angitt i tabellen. Kravtabellen har følgende oppbygning: 1. Kolonne 1 med overskriften KravNr. Dette angir løpenummer for hvert krav innenfor kapittelet. Som det fremgår har også overskriftslinjer over grupper av beslektede krav fått egen linje i kravspesifikasjonen og dermed egne løpenummer. Dette gjør det enklere å kunne henvise til slike grupper av krav. 2. Kolonne 2 med overskriften Prioritet, angir kravets prioritet. Følgende koder er benyttet: Prioritetskode O1 O2 Beskrivelse Betyr absolutte må-krav som skal/må dekkes i første leveranse. Dette er obligatoriske (Mandatory) krav som er absolutte minstekrav. Slike krav bør ikke be om nærmere/utfyllende forklaring (). Betyr må-krav som må leveres, minimum i en senere leveranse. Dette er obligatoriske (Mandatory) krav som ikke er absolutte minstekrav. Slike krav kan ha nærmere forklaring (). Betyr krav som bør være med i løsningen. Dette er valgfrie (Optional) krav. Betyr krav som det er ønskelig å få med i løsningen. Dette er også valgfritt (Optional) krav. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 9 av 35

10 3. Kolonne 3 med overskriften Kravtekst, beskrivelse beskriver det enkelte krav. 4. Kolonne 4 med overskriften Svarkode står åpen. Her skal Leverandør angi en svarkode, som spesifisert i egen tabell nederst i kapittel Kolonne 5 med overskriften, der det er avkrysset for i kolonne 6 under kravteksten skal Leverandør gi en utfyllende kommentar/løsningsbeskrivelse til besvarelsen av kravet. De krav som er avkrysset i denne kolonnen bes besvart av Leverandør ikke bare med en svarkode, men med en utfyllende kommentar/løsningsbeskrivelse. Leverandør står også fritt til å gi utfyllende kommentarer på andre krav, selv om Kunden ikke eksplisitt har bedt om slik kommentar. kolonnen er ofte ikke avkrysset for krav. Dette for å gjøre svarene sammenlignbare og enklere få fram hvilke Leverandører som innfrir minstekravene Leverandørens besvarelse Leverandørens løsningsbeskrivelse skal disponeres i tråd med innholdet i kravtabellene i dette dokumentet. Tabellinnholdet og spørsmålene reflekterer hvilke deler av Kundens behov som må konkretiseres i tilbud som gis. Besvarelsen av de samme punktene danner også utgangspunkt for evaluering av utvelgelseskriteriene for anskaffelsen. Leverandøren bes om å utforme svarene til de respektive punktene i tabellen på en slik måte at det er tydelig på hvilken måte de ulike behovene vil bli ivaretatt. Forhold som ikke naturlig hører hjemme under noen av punktene i kravtabellene, kan kommenteres i eget vedlegg i den grad Leverandøren finner dette relevant. Detaljinformasjon knyttet til besvarelse av enkeltpunkter kan også skilles ut som egne vedlegg der dette er hensiktsmessig for eksempel særskilt spesifikasjon av teknologi eller metoder som tilbys anvendt, samt relevant CV for tilbudte ressurser. Dersom det er enkelte krav eller behov som Leverandøren ikke kan imøtekomme, skal dette fremgå tydelig av besvarelsen. Kunden ber om at Leverandøren setter seg godt inn i Kundens behov og tilpasser tilbud og besvarelse i henhold til dette Strukturering av Leverandørens besvarelse Tilbudet fra Leverandør skal følge strukturen som er angitt i konkurransegrunnlaget kapittel 3.4. Leverandørens besvarelse av Kundens kravspesifikasjonen. Dette vil inngå i bilag 2. Dette skal utformes i samsvar med kravspesifikasjonens kapittelinndeling, dog slik at kapittel 1 utgjør Leverandørens innledning: 1. Innledning (f.eks. med oversikt over tilbudet, forklaring til hvordan kravene er besvart, Leverandørens kontaktpersoner mv.) 2. Implementeringsstrategi 3. Overordnet funksjonell og teknisk løsningsbeskrivelse Svar på Kundens kravspesifikasjon Eventuelle andre bilag og underbilag Leverandørens svar på det enkelte krav skal skrives inn i tabellene i hvert kapittel, som vist i eksemplet nedenunder. Hvert krav skal besvares med en svarkode og eventuelt en utfyllende kommentar, der det er bedt om dette. Utfyllende kommentar skal skrives inn i samme rubrikk som kravet og innledes med bokstavene ":" og deretter den utfyllende kommentar, som vist under. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 10 av 35

11 Krav Prioritet (prio.) Kravtekst, testkriteria Svarkode 1 Krav som skal være testbar når løsningen er implementert Leverandøren bes å beskrive løsningen. : Her skriver Leverandør sin utfyllende kommentar/løsningsbeskrivelse. 2 Passordet skal lagres i AD. Ved første pålogging skal brukeren tvinges til å endre passordet. J J Leverandør må benytte følgende svarkoder: Betydning Forklaring J Ja Kravet er oppfylt i den standardversjon av programvaren som leveres. T S F Tilpasning Kravet oppfylles gjennom normale kundetilpasninger av den standardversjon av programvaren som leveres. Det er Leverandørens ansvar at tilpasningene opprettholdes ved fremtidig installasjon av nye standard-versjoner/revisjoner av programvaren uten manuell inngripen og uten andre kostnader for Kunden enn vanlig programserviceavgift. Svarkode Spesialutvikling Ja, med forbehold Kravet kan etter nærmere avtale bli oppfylt av Leverandøren gjennom spesielle tilpasninger/utvikling, som går utover normale kundetilpasninger av den leverte standard programvare. Ja, kravet kan leveres med forbehold/forutsetninger om N Nei Kravet innfris ikke i den løsning som Leverandøren tilbyr Kunden å implementere. Dette krav lar seg enten ikke innfri eller Kunden må selv sørge for å innfri kravet på annen måte. Dersom svarkoden er T, S eller F skal Leverandøren i sin utfyllende kommentar til kravet angi eventuell kostnad og når et slikt utviklingsarbeid kan utføres. Kunden forbeholder seg retten til å avrope et slikt utviklingsarbeid til angitt kostnad og tid eller velge å avstå fra å bestille oppfyllelsen av dette spesifikke kravet. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 11 av 35

12 3. BEHOVSBESKRIVELSE Dette kapittelet inneholder en overordnet beskrivelse av løsningen med beskrivelse av omgivelse, omfang, interessenter, forutsetninger og funksjonelle krav i en kravtabell Overordnet om løsningen Kunden benytter elektronisk rekrutteringsverktøy i dag. Kunden skal nå fornye/erstatte rekrutteringsverktøyet som Kunden benytter i dag. Dagens rekrutteringsprosesser er beskrevet i sin helhet i kapittel og Elektronisk rekrutteringsverktøy skal dekke de deler som er listet opp i kapittel Omfang (Scope) Elektronisk rekrutteringsverktøy skal benyttes til å markedsføre og rekruttere søkere til Kundens ledige stillinger. Elektronisk rekrutteringsverktøy bør dekke følgende funksjoner: Utlysning av stillinger Utforming av søknadsskjema Søkers registrering av sin søknad og opplasting av vedlegg Mailforsendelse Kandidatrapport med oversikt over alle søkere og all informasjon pr søker Prioritetsliste, søkere til intervju Analyse og statistikk Rapportering Arkivering av journalføringspliktige dokumenter Multi-branding (ulike firmaprofiler med ulik logo, farger, skrift etc) (opsjon) 3.3. Omgivelse (Kontekst) Dette kapittelet gir en overordnet beskrivelse av kontekst/omgivelsen for elektronisk rekrutteringsverktøy. Figuren nedenfor illustrerer relevant kontekst/omgivelse for elektronisk rekrutteringsverktøy. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 12 av 35

13 Figur 2 Kontekstdiagram for elektronisk rekrutteringsverktøy Beskrivelse av figur 2: Rekrutteringsverktøyet er i sentrum og er illustrert med orange runding i midten. Relevant kontekst som er i interaksjon med rekrutteringsverktøyet (objekter, personer og systemer) er illustrert med grå-blå bokser. Pilene illustrerer hvilken vei data flyter mellom kontekst og score (rekrutteringsverktøyet.) Ledige stillinger o registreres i løsningen o publiseres til ulike kanaler fra løsningen Jobb-søker benytter løsningen til å søke ledige stillinger o kan logge seg på via ID-porten o kan laste opp CV ved hjelp av "PortableCV" o kan overføre CV-info fra LinkedIn o kan laste opp vedlegg Leder/rekrutteringsteam for utlysningen via autentiseringsverktøy o logger seg på løsningen Jobb-søker mottar automatiske/manuelle tilbakemeldinger underveis på mail og telefon CV, søknad med vedlegg, søkerlister, fulltekstannonse etc. arkiveres i Kundens arkivsystem (WebSak) Rekrutteringsverktøyet oppdateres med informasjon om nyansatt 3.4. Interessenter Dette kapittelet lister opp oversikt over Kundens interessenter for elektronisk rekrutteringsverktøy: Kundens ansatte ved HR-avdelingen Kundens Jobb-søkere til stillingsannonser Ledere som eier rekrutteringsprosjektet Interne brukere som skal ha tilgang til hele eller deler av rekrutteringsprosjektet Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 13 av 35

14 3.5. Forutsetninger Det forutsettes at en jobb-søknad til Kunden ikke skal inneholde sensitive opplysninger for eksempel fagforeningstilhørighet og helse opplysninger, derfor behøver ikke løsningen være på sikkerhetsnivå nivå 4. (Kunden må påse at søkere får informasjon om dette samt bekrefter at informasjon om dette er lest og forstått) Funksjonell kravtabell Rekrutteringsverktøyet omtales som Systemet i kravtabellene. Tabellen nedenfor inneholder en prioritert kravtabell med de funksjonelle kravene til Systemet. Krav Prio. Kravtekst, testkriteria Svarkode Generelle krav O1 O1 Systemet bør være designet slik at den ikke har et unødvendig antall bilder, fliker og klikk. Det bør for eksempel ikke være separate fliker for personalia, utdanning og arbeidserfaring. Funksjonalitet som hører naturlig sammen i Systemet bør være samlet i ett og samme bilde for søker og interne brukere. Eksempel all informasjon om søker bør ligge på et og samme bilde, herunder personalia, utdanning og arbeidserfaring. Kunden må kunne registrere egendefinerte maler for alle trinn i rekrutteringsprosessen i Systemet, for eksempel maler for stillingsannonser og svarbrev. Systemet må ha automatisk mellomlagring for søker i registreringsprosessen. Systemet må ha automatisk mellomlagring for interne brukere i registreringsprosessen. Systemet må gi mulighet til å dele brukerne inn i ulike definerte nivåer med lese-/skrivetilgang avhengig av nivåtilhørighet. Pålogging Systemet må kunne støtte bruker-autentisering via ID-porten for eksterne brukere slik at søkere kan logges på og identifiseres via ID-porten. Systemet må også kunne støtte pålogging for utenlandske søkere, utenfor IDporten (inntil ID-porten støtter pålogging uten fødselsnummer/d-nummer). Systemet må støtte sømløs overgang (single-signon) fra LinkedIN for søkerne. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 14 av 35

15 Krav Prio. Kravtekst, testkriteria Svarkode Kundens interne brukere må kunne logge seg på Systemet med brukernavn og passord som ligger i AD. Systemadministrasjon Det må være mulig å registrere flere systemadministratorer for Systemet. Systemadministrator må ha mulighet til å endre grafisk profil og maler for hele virksomheten i Systemet. Systemadministrator må ha mulighet til å styre tilganger for rekrutterer, ledere og rådsmedlemmer i Systemet. HR må kunne legge inn og vedlikeholde roller og rettigheter i Systemet. Definering av rekrutteringsprosjekter Systemet må være tilrettelagt for at Kunden kan ha et ubegrenset antall rekrutteringsprosjekter. Systemet må ha funksjonalitet for kopiere tidligere rekrutteringsprosjekter. Systemet må ha et fleksibelt søknadsskjema der Kunden kan legge til obligatoriske og frivillige variabler. Systemet må gi mulighet for å legge inn screeningspørsmål*) for søkere. *) Screeningspørsmål er ofte 2-4 spørsmål som søker må svare på før han går videre i registreringen. På denne måten vet både søker og Kunden om søker har de etterspurte kvalifikasjoner etc. Systemet må legge til rette for fleksibel bruk av bilder og film i stillingsannonsene. Hvilke kanaler søker kan velge mellom for å angi hvor han ble oppmerksom på stillingen må kunne forhåndsdefineres for hvert rekrutteringsprosjekt i Systemet. Kunden må kunne definere innholdet i kandidatrapporten pr rekrutteringsprosjekt og tilpasse variabler etter behov i Systemet. Systemet må gi alle brukere mulighet til å få oversikt over sine rekrutteringsprosjekter, administratorer må ha tilgang til alle rekrutteringsprosjekter. Publisering av stillingsannonse Systemet må støtte overføring og publisering av stillingsannonser til nettsteder og sosiale medier, herunder Kundens hjemmeside, Kundens intranett, NAV, Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 15 av 35

16 Krav Prio. Kravtekst, testkriteria Svarkode Finn.no, LinkedIN, Twitter og relevante jobbportaler. Systemet må støtte dyplenking slik at det i annonsen blir lenket til nettsted for registrering av søknaden til stillingen. Ved endringer og lagring i annonsetekst må det gå automatisk melding om oppdatering til alle rekrutteringskanaler fra Systemet. O1 Søknad Systemet skal ha en lav terskel for søkere, både ved førstegangsregistrering og ved gjenbruk. Beskriv hvordan dette er sikret i Systemet. Systemet må støtte mulighet til å søke flere stillinger uten å registrere CVopplysninger på nytt. Leverandør må beskrive løsning for dette. Systemet skal gi søker mulighet til å velge målform. Det skal minimum være mulig å velge en av følgende målformer i Systemet: bokmål, nynorsk og engelsk. Systemet må gi mulighet for at søker kan registrere hvilken kanal søker ble oppmerksom på stillingen ved hjelp av forhåndsdefinerte alternativer. Systemet må ivareta kravene om "portable cv", ref. Systemet må kunne gi mulighet for at søker på en enkel måte overføre data fra søkers LinkedIN-profil til søknadsskjema i Systemet. Leverandør må spesifisere hvilke data som kan overføres fra LinkedIN. Rekrutterer må kunne endre og legge til opplysninger samt vedlegg for søker også etter søknadsfristen i Systemet. Rekrutterer må kunne registrere søknader manuelt på vegne av søkere i Systemet. Søknadsvedlegg Søker må kunne merke de ulike vedleggene i Systemet ved å laste opp vedlegget på samme område hvor utdanning eller arbeidsforhold registreres. Søker bør kunne legge inn lenke til dokumenter på internett i Systemet framfor å legge selve filen ved søknaden. Søker må ha mulighet til å laste opp flere vedlegg til en søknad i Systemet, minimum 10 stk. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 16 av 35

17 Krav Prio. Kravtekst, testkriteria Svarkode Systemet må håndtere store vedlegg, ett vedlegg må minimum kunne være på 2 MB. Behandling og Strukturering av søknader Systemet må gjøre det mulig å sortere søkere utfra ulike bakgrunnsopplysninger som er lagt inn i søknaden. Det må være mulig for de ulike aktørene å legge inn kommentarer på ulike søkere i Systemet. Slike kommentarer må være tilgjengelig for øvrige beslutningstakere. De ulike brukerne må kunne skrive og samarbeide om vurderinger i Systemet, og/eller laste opp en vurdering Status på søkerne i rekrutteringsprosjektet må komme klart frem i Systemet. Svarmail til kandidater må kunne sendes ut samlet eller hver for seg fra Systemet. Svarmail skal være basert på maler og må kunne redigeres før utsendelse. All arkivverdig kommunikasjon med søkere underveis i prosessen må kunne overføres til elektronisk fra Systemet til Kundens arkivsystem, samlet eller hver for seg. Lister og rapporter Rekrutterer skal kunne produsere både offentlig og utvidet søkerliste i Systemet. I den offentlige søkerlisten i Systemet skal det være mulig å anonymisere søkere som ønsker å være unntatt offentlig innsyn. Systemet skal kunne gi en kandidatrapport med all eller ønsket informasjon om søker. Systemet må støtte mulighet for å skrive ut en samlet oversikt over alle eller et utvalg søkere med søknadstekst, CV og vedlegg på en enkel måte. Systemet må støtte mulighet for å sortere og filtrere kandidatoversikten på ulike kriterier. Beskriv hvilke muligheter som finnes. Kandidater må enkelt kunne rangeres i en søkeroversikt. I Systemets rekrutteringsprosjekter må det komme tydelig fram hvilke søkere som er internt ansatte. Systemet må gi mulighet til å ta ut rapport med oversikt over interne søkere til stillingene. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 17 av 35

18 Krav Prio. Kravtekst, testkriteria Svarkode Avslutning av rekrutteringsprosjektet Systemet må gi mulighet for å registrere når en ansettelse er ferdigstilt, hvem som er ansatt og når vedkommende tiltrer. Som et minimum skal følgende informasjon om prosess og tilsatt kandidat skal lagres fra Systemet i kundens arkivsystem (Acos WebSak) på eget HR-område (PERS): CV og søknad m/vedlegg, fulltekstannonse, søkerlister. Statistikk og rapporter Systemet må gi mulighet for å ta ut statistikk og analysere en rekrutteringsprosess med hensyn til følgende: kostnader kanaler tidsbruk fra oppstart til avslutning av rekrutteringsprosjektet innsamlede data for eksempel utdanningsnivå, utdannelsesgrad, demografiske-data (bosted, alder, kjønn) på søkerne antall rekrutteringer pr divisjon, avdeling, leder Systemet må gi mulighet for å ta ut statistikk og analyse for alle rekrutteringer innenfor valgfrie tidsintervaller, innenfor en divisjon og innenfor en gitt stillingsgruppe eller innenfor en konkret prosess. Systemet må ivareta alle rapporteringskrav fra offentlige myndigheter innenfor et spesifisert tidsrom. Følgende rapporter er aktuelle: gjensidig godkjenning av yrkeskvalifikasjoner for EU/EØS-borgere totalt antall søkere antall kvalifiserte kandidater, antall intervjukandidater antall ansatte med nedsatt funksjonsevne antall ansatte med minoritetsbakgrunn eventuelt antall ansatte med fortrinnsrett Sletting av data I henhold til bestemmelsene i lovverket må Systemet gi automatisk beskjed til søkere om at deres søkerdata vil bli slettet dersom de selv ikke gjør en aktiv handling. Logging- Sporing Systemet må loggføre endringer i rekrutteringsprosjekt som annonsetekst, kontaktperson, søknadsfrist og hvem som har utført dem og når tid. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 18 av 35

19 4. KVALITETSKRAV Kvalitetskravene betegnes også gjerne som "Ikke-funksjonelle krav" som inneholder en del forutsetninger begrensningene som er knyttet til løsningen, for eksempel krav til teknisk plattform samt lover og regler 4.1. Om appendix A Aappendix A ligger bakerst i dette dokumentet hvor de fleste av Kundens kvalitetskrav er plassert av praktiske grunner. Kvalitetskravene i appendix A er en del av bilag 1og har samme gyldighet som øvrige krav i dette dokumentet Krav til integrasjoner Tabellen nedenfor inneholder en prioritert kravtabell med krav til Systemet med hensyn til integrasjon med andre systemer. Krav Prio. Kravtekst, beskrivelse Svarkode Systemet må kunne integreres med relevante publiseringskanaler for stillingsannonser, følgende kanaler må minimum støttes: Kundens hjemmeside, Kundens intranett, NAV, Finn.no, forskning.no, System som driftes eksternt skal kunne hente og benytte autentisering via Azure skybasert brukerkatalog (Active Directory) og "single sign-on" for Kundens medarbeidere (interne brukere, ikke eksterne brukere/søkere). Systemet må kunne integreres med LinkedIN for overføring av informasjon både fra Kunden rekrutteringssystem og søkeren Systemet må kunne integreres med Kundens arkivsystem (Acos WebSak) Systemet må kunne integreres med ID-porten 4.3. Endringer/oppgraderinger Tabellen nedenfor inneholder en prioritert kravtabell med krav til Leverandør med hensyn til endring og oppgraderinger av Systemet og dens plattform. Krav Prio. Kravtekst, beskrivelse Svarkode For systemer som driftes eksterne har Leverandør ansvar for plattformendringer og systemendringer som legges ut i driftsmiljøet. (Kunden har ansvar for plattformendringer og oppgradering av egne enheter som PC, Nettbrett, smarttelefoner.) Leverandør må beskrive vanlig frekvens og rutiner for oppgraderinger. Nye versjoner og oppgraderinger må legges inn uten ekstra kostnader utover årlig lisens Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 19 av 35

20 Krav Prio. Kravtekst, beskrivelse Svarkode Leverandør må oversende informasjon om utfasing av støtte for gamle versjoner på Kundens plattform senest 3 måneder før support av slik programvare opphører. Leverandør må oversende kjente oppgraderingsplaner så fort som mulig og senest 4 uker før installasjon utføres. Leverandør må oversende beskrivelse av ny funksjonalitet i fremtidige leveranser når disse foreligger og senest 14 dager før installasjon utføres. Tekniske endringer i produktet som har konsekvenser for integrasjoner for eksempel endring i grensesnitt som ikke er bakover-kompatibel, må varsles minimum 6 måneder før slik at integrert system også kan rekke å tilpasse og sette i produksjon sine endringer. Ordinære oppgraderinger av systemet og/eller nedetid varsles minimum 7 dager i forveien Leverandør må tilgjengelig gjøre planer for utvikling og oppgradering av systemet for Kunden Leverandør må beskrive Kundens muligheter og rettigheter i forhold til endringer i produktets innhold. Leverandør må ha etablert en ordning for formalisert kundemedvirkning Leverandør må kunne legge frem dokumenterte rutine for behandling av ønsker om endring fra brukere og kunder Leverandør må beskrive rutiner for frys-perioder i forbindelse med oppgraderinger og innføring av endringer. Leverandør må beskrive kundens adgang til å heve avtalen uten ytterligere vederlag hvis oppgraderinger og endringer i tjenesten er utført uten at leverandør har varslet om dette i god tid i forkant 4.4. Produktspesifikt Tabellen nedenfor inneholder en prioritert kravtabell med produktspesifikke krav til Systemet. Krav Prio. Kravtekst, beskrivelse Svarkode O1 O1 Systemet må ha en standardisert symbolbruk for eksempel for progresjon for registrering av søknad, rekrutteringsprosjekt. Systemet bør støtte mulighet for ulike firmaprofiler (multi-branding) med mulighet for å benytte ulike Logoer, farger, bilder, skrifttype og ingresser Systemet bør kunne telle og gi statistikk over antall avbrutte søknadsregistreringer. Leverandør må basert på egne erfaringer, si noe om hvor lang tid det normal tar for å få produktet til å fungere i en ny organisasjon. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 20 av 35

21 Krav Prio. Kravtekst, beskrivelse Svarkode Leverandør skal kort si noe om forventet levetid til produktet i det norske markedet. Det skal fremkomme en komplett liste over mulige utvidelser, med maksimumspriser gjeldene for Kunden i garantiperioden Leverandøren skal kunne presentere i første rekke - nasjonale referansekunder med tilsvarende utfordringer og kompleksitet. Årlig lisens må inkludere oversikt over nivåer av antall brukere Kunden kan benytte i systemet Systemet skal være tilpasset bruk av ulike enheter som pc, nettbrett, Mobil og smarttelefon etc. gjennom responsivt design for både søkere og Kunden som rekrutterer. Systemet må kunne brukes på kundens eksisterende PC-, nettbrett- og mobilplattform Systemet må støtte nyere nettlesere senest 3 måneder etter at de er lansert Leverandør må sørge for kompatibilitet med/støtte for nye nettlesere innen en måned etter at nye versjoner er lansert Webklienten skal være uavhengig av JAVA Systemet skal tilbys som en eksternt driftet tjeneste (SaaS) Leverandør må beskrive arkitektur, driftsmiljø samt hvor driftsmiljøet er plassert. Dersom Systemet leveres som en sky-tjeneste skal det inngås en egen databehandleravtale mellom Kunde og Leverandør. Leverandør må beskrive tiltak for å forhindre og forebygge datainnbrudd samt annen skadelig adferd. Dersom avtalen mellom Leverandør og Kunden opphører skal Leverandøren på forespørsel kostnadsfritt overføre Kundens data til Kunden eller til ny Leverandør på standard utvekslingsformat. Systemet skal oppfylle alle obligatoriske og anbefalte forvaltningsstandarder i gjeldende versjon av referansekatalogen (DIFI's krav og kriterier - Kvalitet på nett og digitale tjenester og krav til nettløsninger WCAG 2.0 ). Leverandør må gi en kort beskrivelse av historikk på hvordan Systemet har blitt utviklet/videreutviklet siste 3 år samt Systemets RoadMap for utvikling/videreutvikling for de neste 3 årene Leverandør må beskrive hvordan sikkerhet for den enkelte søker ivaretatt i Systemet. Herunder beskrive hvordan systemet sikrer at en søker ikke kan se andres søknader (dvs at søker A ikke kan se søker B sine søknader). Leverandør må beskrive hvordan sikkerhet for Kundens data er ivaretatt. Leverandør må beskrive organisasjonens sikkerhetsarbeid og legge ved års-hjul for dette. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 21 av 35

22 5. ANDRE YTELSER OG ØVRIGE LEVERANSEELEMENTER Dette kapittelet beskriver øvrige leveranselementer/ytelser som leveransen omfatter. Dette kapittelet inneholder blant annet en kronologisk oversikt over bestemmelser i avtaleteksten som henviser til krav og endringer som skal fremgå av dette bilaget. (bilag 1) Generelt Statens kjøpsavtale (SSA-K) skal benyttes for kjøp av standard programvare for Kunden. SSA-K avtalen vil bli benyttet selv om det er aktuelt å gjøre enkelte kundetilpasninger i standard programvaren Tilpasninger og installasjon mv (avtalens punkt 2.1.2) Bistand Tabellen nedenfor inneholder Kundens krav til bistand fra leverandøren. Krav Prio. Kravtekst, beskrivelse Svarkode Leverandør skal bistå med å etablere et med helhets-testmiljø, se nærmere beskrivelse kapittel Leverandør må bistå med innføring, konfigurering og igangsetting av systemet. (hva som inngår i prisen og hva som prises separat må framgå av bilag 7). Leverandør må kunne tilby ekstra konsulentbistand på timebasis. Leverandøren utdyper nærmere hvilken type bistand som kan være aktuell 5.2. Dokumentasjon og opplæring (avtalens punkt 2.1.4) Kundens krav til dokumentasjon utover det som fremgår av avtalen er nærmere beskrevet i kapittel 6.5 under appendix A kvalitetskrav. Tabellen nedenfor inneholder Kundens krav til opplæring. Krav Prio. Kravtekst, beskrivelse Svarkode Leverandør skal beskrive nødvendig kompetanseprofil for ulike brukergrupper samt kursbehov for en effektiv forvaltning og bruk av systemet. Leverandør skal gi opplæring til administrator, superbrukere og rekrutterere i Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 22 av 35

23 Krav Prio. Kravtekst, beskrivelse Svarkode HR-avdelingen. Denne opplæring må være inkludert i prisen. Leverandøren skal foreslå og prise opplæring utover den som gis til administrator, superbrukere og rekrutterer i HR-avdelingen som en opsjon Undersøkelsesplikt (avtalens punkt 2.2.2) Tabellen nedenfor inneholder krav til Kundens test av Systemet. Bilag 5 inneholder nærmere beskrivelse av Kundens test av Systemet. Krav Prio. Kravtekst, beskrivelse Svarkode Kunden vil utføre godkjenningsprøve av leveransens standard programvaren. Kunden vil utføre akseptansetest av leveransens kundetilpasninger. Kunden vil utføre helhetstest av leveransen som omfatter både godkjenningsprøve og akseptansetest Testmiljø Tabellen nedenfor inneholder Kundens krav til etablering av testmiljø for Kundens godkjenningsprøve, akseptansetest og helhetstest. Dette miljøet omtales som helhetstest-miljøet. Krav Prio. Kravtekst, beskrivelse Svarkode Leverandør er ansvarlig for å etablere/installere og verifisere helhetstest-miljøet før Kundens godkjenningsprøve, akseptansetest og helhetstest av Systemet skal starte. Tidspunkt for dette må være angitt i Prosjekt- og milepælsplanen i bilag 4. O1 Leverandør er ansvarlig for å vedlikeholde helhetstest-miljøet slik at Kunden kan teste nyer versjoner/leveranser i dette miljøet. Leverandøren må ha et system for registrering av feil og problemer i perioden med Kundens godkjenningsprøve, akseptansetest og helhetstest. Kunden bør ha tilgang til å registrere feil i Leverandørens system for registrering av feil og problemer i perioden med Kundens godkjenningsprøve, akseptansetest og helhetstest. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 23 av 35

24 5.4. Utfylling av avtalebilag Avtalebilagene er forhånds utfylt med generelle beskrivelser som Kunden vil ha med. Kunden har utarbeidet bilag 1 og 3 til ferdig godkjent versjon. Leverandøren skal fylle ut øvrige bilag så langt som mulig. Enkeltpunkter i bilagene kan være gjenstand for spørsmål og avklaringer etter at tilbud er mottatt Eksterne rettslige krav (avtalens punkt 2.7) Kundens krav er følgende: Kundens krav er hovedsakelig spesifisert i dette dokumentet fra kapittel 3-5 og i Appendix A Kundens funksjonelle krav er hovedsakelig spesifisert i dette dokumentet fra kapittel 3- Kundens ikke-funksjonelle krav (kvalitetskrav) er hovedsakelig spesifisert i appendix A Kundens sikkerhetskrav er listet opp i appendix A, kvalitetskrav i kapittel 6.3 Kundens juridiske krav er listet opp i appendix A, kvalitetskrav i kapittel Fri programvare (avtalens punkt 4.3) Krav Prio. Kravtekst, beskrivelse Svarkode Kunden har behov for å kunne videre-distribuere resultatet av leveransen som omfattes av en fri programvarelisens Support Tabellen nedenfor inneholder Kundens krav til support. Krav Prio. Kravtekst, beskrivelse Svarkode O1 Leverandør skal kort beskrive supportapparat som blir gjort tilgjengelig for Kunden samt kompetanse og tilgjengelighet (lokalt og evt. globalt). Leverandør må kunne tilby kostnadsfri support til søkere som bruker systemet pr. epost, i systemet eller pr. telefon. Oppgi tidsrom og evt. andre tidssoner. Leverandør må kunne tilby avtale om support med brukerstøtte for superbrukere og systemadministrator innenfor Kundens kontortid. Brukerstøtten må være lett tilgjengelig på telefon, e-post og evt. nettbasert innenfor Kundens kontortid (mandag fredag kl ). Leverandør bør ha et nettbasert system for rapportering av support saker for problemer og feil Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 24 av 35

25 5.8. Ytelsesnivå i garantiperioden Garantiperioden reguleres i hovedavtalen. Krav utover det som er standard, er lagt inn i tabellen nedenfor. Ytelser i garantiperioden fylles ut dersom vedlikeholdsavtale ikke er inngått. Krav Prio. Kravtekst, beskrivelse Svarkode Kunden skal ha tilgang på supportpersonell og personell som har mulighet til å rette feil i produktet innenfor vanlig åpningstid (08:00 16:00). Det skal være mulig å få tak i supportpersonell pr. telefon eller mail i løpet av maks. to timer. Feilsøking og feilretting i garantiperioden skal være startet etter maks åtte timer, hvis det ikke lar seg gjøre å løse problemet pr. telefon eller over nett. Feilretting i garantiperioden skal være inkludert. Nye patcher og versjoner som kommer i garantiperioden skal være inkludert. Evt. kostnader for installasjon av nye versjoner skal spesifiseres i tilbudet. Frister for utbedring av feil i garantiperioden som er angitt i tabellen nedenfor skal gjelde for leveranse av elektronisk rekrutteringsverktøy til Kunden Kundens definisjoner av feil nivåer for feil i garantiperioden som er angitt i tabellen nedenfor skal gjelde for leveranse av elektronisk rekrutteringsverktøy. Tabellen nedenfor viser frister for utbedring av feil i godkjenningsperioden og garantiperioden. Nivå Kategori Påbegynt feilretting Feilrettingstid innen A Kritisk feil Umiddelbart Uten ugrunnet opphold og senest innen 4 timer. B Alvorlig feil 3 timer Uten ugrunnet opphold og senest innen 8 timer. C Mindre alvorlig feil 10 virkedager Feilen evalueres med sikte på en løsning ved neste programrettelse. Tabellen nedenfor viser Kundens definisjoner av feil nivåer. Disse er felles og gjelder for Kundens, godkjenningsprøve, akseptansetest og helhetstest samt godkjenningsperiode og garantiperiode. Nivå Kategori Beskrivelse A Kritisk feil - Feil som medfører at systemet stopper, at data går tapt eller at andre funksjoner som er kritiske for Kunden ikke er levert eller ikke virker som avtalt. - Dokumentasjonen er så ufullstendig eller misvisende at Kunden ikke kan bruke systemet eller vesentlige deler av det som avtalt. B Alvorlig feil - Feil som fører til at funksjoner som er viktige for Kunden ikke virker som beskrevet i avtalen, og som det er tids- og ressurskrevende å omgå. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 25 av 35

26 Nivå Kategori Beskrivelse - Dokumentasjon er så ufullstendig eller misvisende at Kunden ikke kan benytte funksjoner som er viktige for Kunden. C Mindre alvorlig feil - Feil som fører til at enkeltfunksjoner ikke virker som avtalt, men som Kunden relativt lett kan omgå, og kan aksepteres for en periode. - Dokumentasjon er mangelfull, upresis eller kan lett misforstås. Kunden benytter Jira som verktøy for registrering og oppfølging av saker ( issues ) i perioden med Kundens godkjenningsprøve, akseptansetest og helhetstest samt godkjenningsperioden og garantiperioden. Følgende kategorier benyttes i Jira: Ovennevnte feilkategori /feil nivå Kategori A Kritisk feil Kategori B Alvorlig feil Kategori C Mindre alvorlig feil Kategorier i Jira Blocker, Critical, Major Normal Minor 5.9. SLA Tabellen nedenfor inneholder Kundens minimumskrav til SLA. Krav Prio. Kravtekst, beskrivelse Svarkode Det skal inngås egen SLA mellom Kunde og Leverandør. Leverandøren må legge ved forslag til SLA for drift av Systemet. Leverandør må beskrive hvordan servicenivåer kan justeres over tid, og hvordan de skal måles og rapporteres. Leverandørens anledning til ikke å tilby tjenesten i forbindelse med oppgraderinger og annet vedlikehold, må reguleres i detalj i SLA ved å angi hvilke dager, tidsperiode på døgnet og gjeldende tidssone. Dette fordi Kunden er avhengig at tjenesten leveres kontinuerlig. Kundens og Leverandørens krav til samhandling og rapportering må beskrives i avtalen. Følgende punkter om samarbeid og rapportering bør reguleres slik at Kunden får jevnlige statusoppdateringer/-rapporter Informasjon om hendelser gis til kunden uoppfordret og uten opphold Varsel om oppgraderinger og forbedringer i tjenestene gis kunden i god tid Kunden får mulighet til å eskalere kritiske hendelser på et tidlig tidspunkt Kontaktpunkter hos Leverandøren er beskrevet Partene har anledning til å møtes Kunden kan kreve sikkerhetsrevisjoner eller andre kvalitetsrevisjoner, eventuelt gjennom uavhengig tredjepart Det er beskrevet i hvilken grad Leverandøren kan overvåke og samle inn Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 26 av 35

27 Krav Prio. Kravtekst, beskrivelse Svarkode informasjon om hvordan og i hvilken utstrekning Kunden bruker tjenesten (som frekvens, endringer i volum, samt bruk av båndbredde osv.) Service-nivå (felles eller differensiert) skal beskrives. Sanksjoner for at avtalte servicenivåer ikke er oppfylt skal beskrives. Leverandøren må kunne garantere en oppetid på 99,7 % samt angi tilgjengelighet i absolutte tidsangivelser (t, min pr mnd.) for å få et nøyaktig anslag. Tidsfrist for feilrettinger i tjenestene som er innenfor Leverandørens ansvarsområde og myndighet skal beskrives. SLA må beskrive hvem som er ansvarlig for tap av data og hvordan dette er differensiert i forhold til ulike data. SLA må regulere i hvilke situasjoner avtalen kan sies opp og hvor lang oppsigelsesperiode som skal gjelde. SLA må regulere forhold rundt oppsigelse av avtalen deriblant regler for tilbakelevering/retur, sletting og evt. anonymisering av data SLA må regulere taushetsplikten i samsvar med forvaltningslovens regler. Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 27 av 35

28 6. APPENDI A - KVALITETSKRAV Prioritetskoder som er beskrevet i bilag 1 kapittel benyttes i dette kapittelet også Ytelse og robusthet A Prio. Krav til kapasitet Svarkode 1 Systemet må håndtere 100 aktive brukere internt derav 30 samtidige interne brukere og 100 samtidige eksterne brukere. Systemet må oppfylle krav om responstider (eget krav nedenfor). Dette skal kunne skje på samme tid som systemet utfører normale oppgaver. Det er størst bruk av systemene i ordinær arbeidstid (mandag fredag, kl 07:00-18:00) 2 Systemet skal dimensjoneres slik at krav om responstider (krav nedenfor) er ivaretatt ved topp belastning og ytelsen på Systemet (responstid) skal være stabil og jevn ved økende antall brukere. (Dette skal dokumenteres via egne kapasitetstester). Kapasitetstester skal utføres for større leveranser og nye prosjekter Leverandør skal i samarbeid med Kunden avklare hvilke områder som skal kapasitets-testes for hver gang. Leverandør skal dokumentere utførte kapasitetstester for utvalgte tilfeller. Beskriv metode og mulighet. 3 Systemet skal ikke ha minnelekkasjer. (Dette må dokumenteres via lasttester på t tester) Lasttester skal utføres for større leveranser og nye prosjekter. Leverandør skal i samarbeid med Kunden avklare hvilke områder som skal last-testes for hver gang. Leverandør skal dokumentere utførte lasttester for utvalgte tilfeller. Beskriv metode og mulighet. B Prio. Krav til responstid Svarkode 1 Det er viktig at brukeren opplever rask respons og ikke behøver å vente på at data kommer frem i et skjermbilde. Responstid for oppdatering av skjermbilder skal være lavest mulig, som hovedregel skal den maksimalt være 2 sekunder. Hvis enkeltfunksjoner tar mer enn 2 sek. må dette dokumenteres, begrunnes samt oppgi gjennomsnittlig responstid ved lav, medium og høy systembelastning. Eksempel på slike funksjoner kan være dokumentgenerering, innhenting av store lister eller integrasjon med andre systemers tjenester. 2 Systemet skal ha mulighet for å benytte standard testverktøy til automatisk ytelsestest og stresstesting. (Responstid ved lavt, middels og høyt antall brukere og belastning skal dokumenteres via ytelsestester og stresstester). Beskriv mulighetene. C Prio. Krav til tilgjengelighet (og pålitelighet) Svarkode 1 Systemet skal ikke stoppe, men skal være tilgjengelig selv om ett eller flere av integrerte systemer, tjenester og databaser ikke er tilgjengelige. Funksjoner som ikke er avhengig av integrerte systemer/tjenester skal kunne benyttes selv om integrerte systemer/tjenester ikke er tilgjengelige. Hensikten med dette kravet er at hvis omkringliggende og integrerte systemer blir utilgjengelige eller slutter å fungere som Kommentar / Referanse Kommentar / Referanse Gjør et utvalg av bestemte skjermbilder som skal testes Kommentar / Referanse Prosjektmandat mal basert på Difis mal for Prosjektmandat Side 28 av 35