Fra behov til prioriterede krav — uden at leverandøren styrer beslutningen.
Kort fortalt
- Skriv hvad I skal kunne opnå — ikke hvilken knap der skal findes.
- Brugerhistorier ("som [rolle] vil jeg [behov], så jeg kan [værdi]") afslører misforståelser tidligt.
- Prioritér hårdt: når alt er vigtigt, er intet det.
En kravspecifikation er ikke en ønskeseddel. Det er et prioriteret, fælles grundlag, der gør jer i stand til at sammenligne løsninger på samme præmis — og holde leverandøren til ilden.
Start med behovet, ikke funktionen
Skriv hvad I skal kunne opnå, ikke hvilken knap der skal findes. “Vi skal kunne følge en sag fra modtagelse til afslutning” er et behov; “der skal være en statuskolonne” er en løsning, der låser jer fast for tidligt.
Brug brugerhistorier
Formatet “Som [rolle] vil jeg [behov], så jeg kan [værdi]” tvinger jer til at tænke i, hvem der får gavn af kravet, og hvorfor. Misforståelser opdages tidligt, mens de stadig er billige at rette.
Prioritér hårdt
- ✓Must-have — uden dette er løsningen ubrugelig
- ✓Should-have — vigtigt, men der findes en midlertidig vej udenom
- ✓Nice-to-have — rart, men ikke afgørende for et valg
Når alt er “vigtigt”, er intet det. Prioriteringen er det, der gør specifikationen til et beslutningsværktøj i stedet for en ordliste.
Et godt kravkatalog reducerer risikoen for det dyreste fejlkøb: den forkerte løsning.
Hvad et godt krav ser ud som
Forskellen på et godt og et dårligt krav er, om det kan testes. "Systemet skal være brugervenligt" kan ingen leverandør sige nej til — og ingen kan bevise, at det er opfyldt. "En sagsbehandler skal kunne oprette en ny sag med kunde, emne og ansvarlig på under ét minut uden at forlade skærmbilledet" kan derimod både demonstreres og efterprøves.
Skriv derfor kravene, så de indeholder en rolle, en handling og et resultat, og tilføj gerne et acceptkriterium: hvad skal vi se, for at kravet er opfyldt? Det gør det langt nemmere at sammenligne leverandører og at teste, når systemet er leveret.
Funktionelle og ikke-funktionelle krav
De fleste kravspecifikationer er gode til de funktionelle krav — det, systemet skal kunne gøre. De ikke-funktionelle krav glemmes oftere, selvom de ofte afgør, om løsningen holder i praksis:
- ✓Integration: hvilke systemer skal der udveksles data med, og hvor ofte?
- ✓Sikkerhed og adgang: hvem må se og ændre hvad, og hvordan logges det?
- ✓Drift og support: svartider, oppetid, sprog, og hvem I ringer til, når noget fejler
- ✓Data: hvor ligger data, hvordan kommer I ud igen, og hvad koster det at tage dem med?
Hvor mange krav skal der være?
Færre, end de fleste tror. Et kravkatalog med 300 linjer bliver ikke læst — hverken af leverandøren eller af jer selv. Sigt efter et sted mellem 30 og 60 krav for et almindeligt system til en mindre eller mellemstor virksomhed, hvoraf måske 10–15 er must-have. Det tvinger jer til at prioritere, og det gør det muligt at bruge kravene aktivt i leverandørdemoer og i den afsluttende test.
Fra kravkatalog til beslutning
Kravkataloget er ikke færdigt, når det er skrevet. Brug det til at bygge en evalueringsmodel: giv hvert must-have-krav en vægt, bed leverandørerne svare på hvert krav med "standard", "kræver tilpasning" eller "kan ikke", og score dem ens. Læg dertil en vurdering af totalomkostninger over tre til fem år — licens, implementering, integrationer, uddannelse og drift — så I sammenligner den fulde pris og ikke kun tilbudssummen.
Resultatet er et beslutningsgrundlag, ledelsen kan forholde sig til, og som kan forklares til dem, der skal leve med systemet bagefter. Det er den bedste forsikring mod det dyreste fejlkøb af alle: den forkerte løsning.
Sådan kan jeg hjælpe: Systemer — Alignment — faste pakker fra 17.500 kr.
Se også videoen: Skal I have nyt system? Så start ikke der