Hensikt og omfang

For å sikre god kvalitet på leveranser til Helse Midt-Norge skal det utarbeides kravspesifikasjoner for det som skal leveres.

Denne prosedyren beskriver hvordan kravspesifikasjoner skal utarbeides. Metode for å utarbeide kravspesifikasjonen må vurderes i det enkelte prosjekt avhengig av prosjektets omfang, anskaffelsesmetode og kontraktstype.  

 

Ansvar

Prosjektleder har ansvar for at det utarbeides kravspesifikasjoner. Prosjektleder har ansvar for å trekke inn brukere, ledere, arkitekter og annen nødvendig kompetanse etter behov.

 

Arbeidsbeskrivelse

Generelle retningslinjer for utforming av spesifikasjoner

Kravspesifikasjonen skal ta utgangspunkt i de behovene som anskaffelsen skal løse og de gevinstene anskaffelsen er tenkt å gi. Kravspesifikasjonen skal, der det er mulig, gi leverandørene mulighet til å foreslå ulike løsninger på behovene som beskrives.

Svært ofte er det nyttig å gå igjennom de prosessene som vil påvirkes av anskaffelsen for å få en klar oppfatning av hva kravene bør være for å bidra til å forbedre arbeidsprosessene. Hemit sine arkitekter er en god ressurs som har erfaring med å gjennomføre slike gjennomganger.

 

Praktiske råd for å lykkes med en kravspesifikasjon:

·        Språket må være presist og utvetydig.

·         Vær nøye med å skille på bør-krav, og skal-krav, i formulering av setninger. De fleste funksjonelle krav bør være bør-krav. Dersom et skal-krav ikke er oppfylt i et tilbud, vil tilbyder bli forkastet fra anbudskonkurransen.

·        Man skiller mellom funksjonelle krav (krav til virkemåte) og egenskapskrav (krav til sikkerhet, ytelse, drift og vedlikehold etc.).

·        Ingen overlappende krav: krav skal bare beskrives ett sted. Alle andre steder i samme dokument og i andre dokumenter må man vise til den opprinnelige beskrivelsen, og ikke gjengi det samme kravet på en ny måte.

·         Grupper kravene: lag undergrupperinger for å gjøre det enklere for leverandør å besvare og enklere for oss å evaluere.

·         Bruk krav-id: nummerer kravene entydig og på samme måte til alle leverandører, og disse må være uendret gjennom hele anskaffelsen. Om vi ikke følger dette rådet gjør vi arbeidet med evalueringen vanskeligere for oss selv. Når leverandørers svar skal sammenlignes og det skal gis presiseringer og utfyllende informasjon til et krav er det obligatorisk å kunne referere til en nummerering som er den samme for alle.

·        Krav skal ikke gi føringer for hvordan kravet skal løses teknisk. Prosjektet og leverandør må kunne vurdere alternative løsninger for å oppfylle kravet. Dersom det likevel stilles absolutte krav til bestemte løsninger, bør dette beskrives som ytre forutsetninger for prosjektet.

·        Krav skal formuleres testbare, der mulig, og skal bl.a. danne underlag for testplaner. I praksis betyr det at krav må være målbare og etterprøvbare. Krav av type "godt brukergrensesnitt" har ingen praktisk nytteverdi, man må dekomponere begrepet "brukergrensesnitt" og angi målbare krav til hver enkelt delkomponent.

·         Bruk vedtatte styringsdokumenter som en del av grunnlaget når kravene utformes. Se oversikten under.

 

Grunnlag for krav til informasjonssikkerhet og personvern (egenskapskrav til løsningen)

Krav til informasjonssikkerhet og personvern skal alltid beskrives. Følgende styringsdokumenter gjelder for alle IKT-anskaffelser og egenutviklinger i HMN vedrørende krav til, og evaluering av, informasjonssikkerhet og personvern:

 

·         NO-18 Kravspesifikasjon IKT-tjenester og informasjonssikkerhet for MTU - Helse Midt-Norge (Ikke tilgjengelig): dokumentet skal brukes som grunnlag for kravspesifikasjon til tekniske krav ved anskaffelser.

o   Deler av kravene i dette dokumentet er spesifikt rettet mot behandlingsrettede helseregistre. Disse vil ikke være relevante for andre system, og skal da ikke tas med.

o   Det anbefales at de kravene som er relevante plukkes ut i et separat kravdokument til prosjektet, og ikke at dokumentet i sin helhet utleveres til en leverandør med mindre samtlige krav er aktuell.

·         NO-19 Sikkerhetsprinsipper og -krav til IKT-infrastruktur og -tjenester (Ikke tilgjengelig): dokumentet skal brukes til evaluering/vurdering av leverandørens tilbudte løsning innenfor områdene IKT-og informasjonssikkerhet. I tillegg skal den i størst mulig grad kartlegge løsningens grunnleggende funksjonalitet og egnethet i oppdragsgivers IKT-infrastruktur i forkant av et endelig kundedesign.

 

Form på kravspesifikasjonene

Metode og form på kravspesifikasjoner for spesielt de funksjonelle kravene bør tilpasses hva som er mest hensiktsmessig for prosjektet.

 

Tradisjonell kravliste:
Dette er en opplisting av krav i setningsform. Se maler på tradisjonelle kravlister som vedlegg til denne prosedyren: «mal kravspesifikasjon kjøpsavtale» og/eller «mal tradisjonell kravspesifikasjon (excel)».

·         Egenskapskrav (krav til sikkerhet, ytelse, drift og vedlikehold etc) bør med fordel alltid listes opp i en tradisjonell kravliste.

·         Kravformen kan benyttes også for funksjonelle krav.

Ved prosjekter der mye nytt skal utvikles og prosjektet gjerne gjennomføres med smidig metodikk er personas, rask prototyping, brukerhistorier og/eller brukstilfeller mer egnet som funksjonell kravspesifikasjon enn tradisjonell kravliste:

Brukstilfeller (Use Case):
Generelt er brukstilfeller en mye brukt spesifikasjonsform, og normalt bedre egnet enn en tradisjonell kravliste for funksjonelle krav. Brukstilfeller er svært utbredt i IKT-prosjekter i Norge og internasjonalt. Se mal for brukstilfeller.

Brukerhistorier (User Stories):
Ved smidig utvikling der utviklingsteamet har tett og kontinuerlig kontakt med kunden, benyttes mal for brukerhistorier. Litt unøyaktig kan man si at brukerhistorier er en forenklet form av brukstilfeller.

Kombinasjon av brukerhistorier og brukstilfeller:
Ved smidig utvikling der kunden ikke kan sitte sammen med leverandør hele tiden, men likevel ha et tett samarbeid, har Helse Midt-Norge gode erfaringer med å kombinere brukerhistorier og brukstilfeller. Da har Helse Midt-Norge ansvar for å lage brukerhistoriene, mens leverandør har ansvar for å lage brukstilfellene (i tett samarbeid med oss). Brukerhistorier (sammen med leverandørens grovestimater) kan være tilstrekkelig underlag for å inngå en smidig-kontrakt, mens brukstilfellene utarbeides i samarbeid mellom leverandør og prosjektet underveis i prosjektet. Det er ikke alltid nødvendig å lage brukstilfeller for alle brukerhistoriene, dette vurderes av prosjektet underveis.

Rask prototyping (Rapid Prototyping):
For noen prosjekter kan skissering av skjermbilder være minst like godt egnet som brukerhistorier. Helse Midt-Norge har med hell benyttet verktøyet Balsamiq til dette formål. Helse Midt-Norge har tilgang til en skytjeneste for bruk av Balsamiq, hvor det bl.a. finnes mekanismer for versjonshåndtering og sporbarhet på alle endringer som gjøres på skissene som lages.

Personas

Bruk av personas er en metode som kan benyttes for å presentere en målgruppe, og beskrive målgruppens krav og forventninger. Dette benyttes ofte i prosjekter som skal etablere løsninger for brukerkommunikasjon (utvikling av nettsider, selvbetjeningsløsninger, nye app’er, etc.). Personas er ikke ekte brukere, men oppdiktede stereotypier av typiske brukere, som hver er en representant for en kategori brukere. Personas beskrives så levende som mulig, gjerne som et portrett av en (tenkt) person.

 

Grunnlag for utarbeidelse av anbudsunderlag

Ved gjennomføring av offentlige anbud av IKT-prosjekter skal Hemits kontraktsleder og Sykehusinnkjøp HF involveres. Tjenesteutvikler bør også involveres.

·         Mal for Statens standardavtaler (SSA) skal benyttes som kontraktsmal ved anbud, se omtale på Anskaffelser.no. Avgjør hvilken av Standardavtalene (SSA) som skal benyttes, dette avgjøres i prosjektet i samråd med Hemit sin kontraktsleder og Sykehusinnkjøp. SSA-T, SSA-K, SSA-L, eller SSA-sky er aktuelle[1], eventuelt SSA-S om prosjektet skal gjennomføres med smidig metodikk. I disse avtalene skal det fylles ut Bilag 1-10 som beskriver leveransen og prosjektet.

o   Bilag 1 i den valgte SSA-avtalen skal inneholde funksjonelle krav og egenskapskrav til løsningen. Det anbefales at kravene sammenfattes i et, eller flere, separat(e) dokument(er) som vedlegg til bilag 1, og utformes på en (eller flere) av de valgte kravformene over. Sikkerhetskravene må inn i henhold til avsnitt over: Grunnlag for krav til informasjonssikkerhet og personvern (egenskapskrav til løsningen). 

o   Bilag 3: Kundens tekniske plattform (KTP) skal beskrives i bilag 3 i SSA-avtalen. Den finnes her: Kundens Tekniske Plattform (Ikke tilgjengelig). Beskrivelsen må benyttes i alle anskaffelser og gir leverandøren innsikt i den løsningen som anskaffelsen blir en del av. Merk, det bør gjøres en sjekk på om noe er utdatert da denne revideres bare annethvert år.

o   Bilag 5:  Avtaleinngåelse, bruk av mal til SSA-T Bilag 5 Testing og godkjenning (Ikke tilgjengelig). «Mal for SSA-T Bilag 5 Testing og godkjenning» er beregnet brukt til bilag 5 dersom SSA-T Utviklings og tilpasningsavtalen er valgt. Dersom det er valgt andre kontraktsmaler for anbud enn SSA-T, kan likevel malen benyttes som sjekkliste da mange av punktene er generelle.

·         Databehandleravtale skal legges med i anbudsutlysning som vedlegg. Det bør være et skal-krav i kravspesifikasjonen at databehandleravtale skal signeres. Se rutine: Inngåelse av databehandleravtale (Ikke tilgjengelig).

·         SSA-V skal alltid også utformes for avtale om videre vedlikehold av anskaffelsen etter prosjektslutt.

Se også rutine for anskaffelser: Anskaffelser.

Referanse

Viktige dokumenter er blant annet:

http://www.normen.no/

HMN Sikkerhetsplan

Arkitekturplan - Helse Midt-Norge