Hvordan det ser ut
Kravene beskriver knapper, menyer, skjermbilder og databasetabeller. «Systemet skal ha en nedtrekksmeny for avdeling.» «Det skal sendes e-post ved statusendring.» Alt er konkret, alt er testbart, og alt er svar på spørsmål ingen stilte.
Den oppstår sjelden av vond vilje. Den oppstår fordi det er lettere å beskrive noe du har sett, enn noe du trenger. Folk beskriver dagens system med små forbedringer.
Hva det koster
Du betaler for spesialtilpasning. Leverandøren har kanskje en ferdig komponent som løser behovet. Har du spesifisert noe annet, må det bygges.
Du overtar ansvaret. Dette er det alvorligste. Har leverandøren bygget nøyaktig det du beskrev, og det ikke løser problemet, er det din regning. Beskriver du behovet, er det leverandørens ansvar at løsningen dekker det.
Du får dagens arbeidsmåte i ny innpakning. Hele gevinsten ved et nytt system ligger som regel i at noe kan gjøres annerledes. Beskriver du dagens flyt som krav, har du kjøpt bort den muligheten.
Hva du gjør i stedet
Still spørsmålet «hvorfor?» til hvert konkrete krav, til du treffer en forretningsmessig grunn du ikke kan grave videre i. Det er behovet. Metoden er beskrevet i beskriv behovet, ikke løsningen.
Interoperabilitet, regelverk, forvaltbarhet og eksisterende lisenser. Skal systemet snakke med Altinn, er protokollen et reelt krav. Har dere fem systemer på samme plattform og én driftsavdeling, er teknologivalget et reelt virksomhetsbehov. Lås løsningen når en av disse gjelder — og skriv én setning om hvorfor, så neste generasjon vet om grunnen fortsatt finnes.