Kravspesifikasjon til en systemanskaffelse

Kravspesifikasjonen utgjør en vesentlig del av konkurransedokumentene i en systemanskaffelse og må henge godt sammen med konkurransegrunnlaget.

Publisert: 11. Mai 2018, Sist endret: 14. nov 2018

Mål og gevinster

Målet for anskaffelsen og hvilke gevinster du ønsker å oppnå, må være beskrevet tydelig. Beskrivelsen kan hjelpe leverandøren til å bruke sin kompetanse til å foreslå gode løsninger i tilbudet sitt. 

Målet for anskaffelsen

Start gjerne med å beskrive kort hvordan målet for anskaffelsen er forankret i overordnede styringsdokumenter som tildelingsbrev, stortingsmeldinger og liknende og hvordan det henger sammen med virksomhetens samfunnsoppdrag.

Gevinster

Beskriv hvilke gevinster dere planlegger å realisere. Legg gjerne ved gevinstavtaler, dersom de er inngått allerede. Be gjerne leverandøren utdype hvilke forutsetninger som må være på plass for å kunne ta ut disse gevinstene. Oppfordre leverandøren til å skissere andre gevinster som det kan være mulig å ta ut og hvilke forutsetninger det i så fall vil kreve.

Beskrivelse av nåsituasjonen

Hvis leverandøren får en god forståelse av nåsituasjonen og hva som er utfordringsbildet, er det lettere å lage tilbud.

Mange digitaliseringsløsninger er komplekse og skal fungere i en kompleks sammenheng. Det er derfor lurt å legge energi i å beskrive relevante deler av organisasjonen som blir berørt av løsningen.

Tenk på at de som skal lese kravspesifikasjonen ikke kjenner til den virksomheten som skal ha løsningen. Hva vil være nyttig for dem å vite?

  • Organisasjonskart, med fysisk plassering, dersom det er relevant, og beskrivelse av ansvarsområdene.
  • Tegninger som beskriver arbeidsprosesser.
  • Rutinebeskrivelser og liknende.

Husk å beskrive hva forkortelser betyr og forklare faguttrykk. 

Bruk av standarder

Bruk av åpne standarder er viktig for å:

  • Unngå låsing til én leverandør og å sikre at digitale løsninger fungerer sammen.
  • Fremme elektronisk samhandling med og i forvaltningen. 
  • Fremme konkurranse mellom tilbyderne og å begrense leverandøravhengighet.

Forskrift om IT-standarder i offentlig forvaltning skal bidra til at et hvert organ for stat eller kommune, jf. forvaltningsloven § 1 første punktum, tar i bruk tekniske, semantiske og organisatoriske IT-standarder som legger til rette for dette.

Forskriften omfatter obligatoriske standarder som det skal stilles krav om dersom de er relevante for systemet som skal anskaffes. Standardiseringssidene på difi.no inneholder både de standardene som er obligatoriske etter forskriften og anbefalte standarder.

Funksjonelle behov

Hvordan beskrive krav til funksjonaliteten i systemet på en måte som sikrer fleksibilitet i løsningsutformingen?

Detaljerte krav begrenser handlingsrommet både i leverandørens tilbud og i den løsningen kunde og leverandør skal samarbeide om å utvikle etter kontraktsinngåelse.    

Tabeller er greie å bruke under evalueringen av tilbud, men forutsetter at kravbeskrivelsene er korte. Skal du forklare behovene dine mer inngående, blir tabellene uoversiktlige og vanskelige å lese.

Du bør derfor beskrive den funksjonaliteten du trenger i form av behov istedenfor krav, og gjerne i en sammenhengende tekst.

Det er viktig at du gir leverandøren nøyaktige instruksjoner om hva de skal svare på og hvordan de skal utforme besvarelsen.

Det er også viktig at du gir leverandøren grundig begrunnelse for evalueringsresultatet, og at du kan dokumentere hvordan du er kommet frem til det.   

Kvalitetskrav

Forslag til ulike typer kvalitetskrav som det kan være aktuelt å ha med i kravspesifikasjonen.

Med kvalitetskrav mener vi krav som går på egenskaper ved løsningen, det vil si krav som ikke er relatert til funksjonaliteten i løsningen. Eksempler på kvalitetskrav er krav til teknisk platform for løsningen, responstid, kapasitet, sikkerhet med mer. For å legge til rette for å ha så stort handlingsrom som mulig er det viktig å holde kravene på et overordnet nivå og ha så få absolutte krav som mulig.  

Eksempler på krav som du vanligvis bør ha med

  • Krav om å støtte relevante deler av kundens tekniske plattform
    • Beskrivelse av hvilke tekniske løsninger virksomheten bruker, inkludert fysisk plassering dersom dette er relevant
    • Beskrivelse av teknisk støtteorganisasjon, for eksempel systemadministrasjon og -drift 
  • Arkitekturkrav
  • Integrasjoner
    • Teknisk beskrivelse av systemet integrasjonen gjelder
    • Hvilke muligheter er det for utveksling av data?
    • Hvilke data skal integrasjonen omfatte?
    • Hvor ofte skal dataene oppdateres?
  • Krav til responstid/ytelse ved ulike former for transaksjoner
  • Krav til kapasitet - hvor mange transaksjoner samtidig, hvor store datamengder
  • Robusthetskrav (for eksempel krav om kvalitetskontroll av data som legges inn i systemet)
  • Krav til forvaltbarhet (at det skal være lett å videreutvikle løsningen når nye behov oppstår)
  • Krav til sikkerhet (se eget steg)

Sikkerhetskrav

Sikkerhetskrav omfatter både regelverkskrav, krav til teknisk sikkerhet i løsningen, tilgangsstyring hos kunde og leverandør og krav til håndtering av data. 

Hvordan skaffer du deg kunnskapsgrunnlag for å stille sikkerhetskrav?

  • Veilederen "Internkontroll i praksis - informasjonssikkerhet" beskriver hvordan du kan gå frem for å finne ut hvilke behov dere har på sikkerhetsområdet og hvordan de bør håndteres i forbindelse med en anskaffelse.    
  • Regelverk på det området som systemet støtter kan være opphav til sikkerhetskrav.
  • En del sikkerhetskrav er funksjonelle krav, for eksempel krav til tilgangsstyring - hvem skal ha tilgang til hva, og hvilke roller må systemet håndtere?
  • Skal innbyggere eller andre eksterne brukere kunne logge seg inn i løsningen? I så fall på hvilket sikkerhetsnivå?
  • Du må gjøre en risikovurdering av det området som systemet skal støtte. I risikovurderingen ser du på hva som kan gå galt og hvilke konsekvenser dette kan få. Risikoer som ikke kan aksepteres som de er, må håndteres. På områder hvor du selv skal ha ansvaret foreslår du risikoreduserende tiltak og iverksetter disse. Risikoer på områder hvor leverandøren skal komme med løsninger gir grunnlag for å stille sikkerhetskrav i kravspesifikasjonen.
  • Er det aktuelt med vedlikeholdsavtale - still sikkerhetskrav til de som skal utføre vedlikeholdet - for eksempel sertifiseringskrav til leverandøren.
  • Er det aktuelt med IT-tjenestekjøp som for eksempel skytjenester eller utsetting av driften? Da må du tenke på hvilke sikkerhetskrav til du må stille til driftsleverandøren og huske på å inngå databehandleravtale og ha regulert av overføring av data ved opphør av avtalen.
  • Risikovurderinger - sikkerhetstesting - har du kompetanse internt eller må du leie inn hjelp på kundesiden?

Det er viktig at du tenker på at du skal "kjøpe handlingsrom". Hold deg på et overordnet nivå når det gjelder krav til løsning og legg energien i å beskrive mål og gevinster, rammer og føringer. 

Hvordan kravspesifikasjonen skal utformes avhenger av hvilken kontrakt du har valgt.  

Kravspesifikasjonen må ikke være for detaljert

Beskriv det funksjonelle behovet, ikke "drømmeløsningen". 

En detaljert kravspesifikasjon setter føringer for hvordan behovet teknisk skal løses. Dette hindrer både utnyttelse av kompetansen i leverandørmarkedet og muligheten til å utvikle de gode løsningene som kunde og leverandør kommer frem til i fellesskap.

 

Konsekvenser av at kravspesifikasjonen setter detaljerte føringer

  • Leverandøren kan ikke tilby de løsningene de mener er best fordi de ikke vil oppfylle de detaljerte kravene i kravspesifikasjonen.
  • Prosjektet er en læringsarena, og de løsningene kunde og leverandør sammen kommer frem til er best, kan være veldig forskjellige fra de som er beskrevet i den detaljerte kravspesifikasjonen.
  • Du kan risikere at leveransen blir vesentlig endret i forhold til utlysningen, noe som er i strid med regelverket.

Kravspesifikasjonen må ikke være for gammel

Ofte utarbeides kravspesifikasjonen tidlig i prosjektet. Så går det kanskje flere år før finansieringen er på plass. Hvis du ikke oppdaterer kravspesifikasjonen, ender du opp med å anskaffe en utdatert løsning.

 

Konsekvenser av at kravspesifikasjonen er for gammel

  • Kanskje stemmer ikke beskrivelsen i kravspesifikasjonen med hvordan arbeidsoppgavene løses nå?
  • Kanskje er beskrivelsen av teknisk plattform utdatert?
  • Kanskje er det kommet nye tekniske løsninger på markedet?

 

Deldette

Fant du det du lette etter?

Fant du det du lette etter?
*