Kravspesifikasjon.comIngen skal måtte være ekspert

ForsidenDokumentet › Ikke-funksjonelle krav

8. Ikke-funksjonelle krav

Funksjonene bestemmer hva systemet gjør. De ikke-funksjonelle kravene bestemmer om det er til å leve med — og de bestemmer prisen. To løsninger med identisk funksjonsliste kan skille en faktor to på pris utelukkende på grunn av dette kapittelet.

Et ikke-funksjonelt krav sier noe om hvordan systemet skal være, ikke hva det skal gjøre: hvor raskt, hvor sikkert, hvor tilgjengelig, hvor lett å drifte, hvor godt det håndterer personopplysninger. De kalles ofte kvalitetskrav, og det er et bedre navn.

Kapittelet blir gjerne kort fordi det er ubehagelig å tallfeste. Men et vagt kvalitetskrav er verre enn ingen: det ser ut som en avtale uten å være det.

Områdene du bør gå gjennom

OmrådeSpørsmålet du må svare på
YtelseHvor raskt, ved hvilken belastning, målt hvor?
Kapasitet og vekstHvor mye data og hvor mange brukere om fem år?
TilgjengelighetHvor mye nedetid tåler dere, og i hvilket tidsrom?
SikkerhetAutentisering, tilgangsstyring, logging, sårbarhetshåndtering
PersonvernBehandlingsgrunnlag, sletting, innsyn, databehandleravtale
Universell utformingHvilken standard, og hvem verifiserer den?
Drift og overvåkingHvem drifter, hvordan varsles feil, hvilke rapporter?
Integrasjon og åpenhetDokumenterte grensesnitt, standarder, dataformater
Dataeierskap og exitHvem eier dataene, og hvordan kommer dere ut?
Språk og lokaliseringBokmål, nynorsk, samisk? Grensesnitt og støtte
Ferdige formuleringer

Vår søsterside har en katalog over ikke-funksjonelle krav med ferdigskrevne formuleringer du kan ta utgangspunkt i. Vi gjentar den ikke her — det du trenger fra oss er hvordan du velger blant dem og gjør dem målbare.

Tallfest, ellers er det ikke et krav

Dette er kapittelet der adjektiver gjør mest skade. «Systemet skal være raskt» er oppfylt av enhver løsning, fordi ingen kan bevise det motsatte. Se tall i stedet for adjektiver.

Svakt

Systemet skal ha god ytelse og høy tilgjengelighet, og skal ivareta sikkerhet og personvern på en tilfredsstillende måte.

Bedre

K-401 (skal) Søk i saksarkivet skal returnere første treffside innen 2 sekunder ved 500 000 saker og 30 samtidige brukere, målt i nettleseren hos sluttbruker.

K-402 (skal) Løsningen skal ha en tilgjengelighet på minst 99,5 prosent målt per måned i tidsrommet 07:00 til 17:00 på virkedager, med unntak for avtalt vedlikeholdsvindu.

K-403 (skal) Personopplysninger skal kunne slettes på forespørsel innen 30 dager, inkludert i sikkerhetskopier eldre enn 12 måneder.

Legg merke til at hvert krav sier hvor det måles. «Under 2 sekunder» målt på serveren og målt i nettleseren er to ulike løfter, og forskjellen er der brukeren bor.

Vær forsiktig med å overspesifisere

Kvalitetskrav er dyre. Å gå fra 99,5 til 99,9 prosent tilgjengelighet kan doble driftskostnaden, og forskjellen er 26 minutter nedetid i måneden. Spør ved hvert tall: hva skjer faktisk hvis vi ligger like under? Er svaret «ingenting alvorlig», har du satt tallet for høyt.

Det samme gjelder svartider. Kravet bør speile hva arbeidet tåler, ikke hva som høres imponerende ut. Se gullbelegging.

Personvern hører hjemme her, ikke i et vedlegg

Behandler løsningen personopplysninger, er databehandleravtale, sletterutiner, logging, innsyn og lagringssted ikke formalia — de er krav som påvirker både arkitektur og pris. Skriv dem som krav med nummer, slik at de kan besvares, evalueres og etterprøves som alt annet.

Vurder også hvor dataene skal ligge, og hvem som kan få tilgang til dem. Det er et spørsmål som har konsekvenser for hvilke leverandører som i det hele tatt kan by.

Drift er en kostnad som varer

Anskaffelsesprisen er én gang. Driftskostnaden er hvert år i hele levetiden, og den er som regel den største samlede posten. Krav til drift, forvaltning, oppgraderinger og support hører derfor med i evalueringen — ikke bare i kontrakten. Se kapittel 12 og driften ingen priset.

Vanlige feil

  • Kapittelet er en halv side. Da har dere sannsynligvis ikke tenkt gjennom drift, sikkerhet eller vekst — og kostnaden kommer likevel.
  • Standarder uten versjon. Vis til konkret standard og versjon, og til hvordan etterlevelse dokumenteres.
  • Krav uten målepunkt. Et ytelseskrav uten belastning og målested kan ikke etterprøves. Se kravet må kunne bevises oppfylt.
  • Kopiert katalog uten vurdering. Å lime inn 34 kvalitetskrav uten å tilpasse tallene gir en dyr løsning der ingen vet hvilke tall som betyr noe.