Så skiljer du krav från önskemål i en kravspecifikation

Varför gränsdragningen avgör om kravspecen fungerar

Enligt Genesis IT är en kravspecifikation – ofta förkortad kravspec – ett dokument som beskriver vad ett system eller en produkt ska göra och vilka krav som ställs på det. Dokumentet är centralt vid utveckling och upphandling av IT-system, men används också i produktutveckling, byggprojekt och vid inköp av tjänster.

Vad kravspecen ska åstadkomma förklarar varför gränsdragningen mellan krav och önskemål måste göras tidigt. Genesis IT lyfter fyra funktioner: den skapar gemensam förståelse mellan beställare och leverantör och minskar risken för missförstånd och fel; den ger underlag för att planera projektet, uppskatta tidsåtgång och kostnader och fördela resurser; den är en central del av förfrågningsunderlaget och gör att olika anbud kan jämföras objektivt; och den är underlag för utveckling och testning. Jämförelsen blir bara objektiv om det framgår vilka egenskaper som är ett måste och vilka som vägs in som kvalitetsparametrar.

Fiive beskriver samma sak för mjukvaruutveckling: en bra kravspec ska förklara problemet ni vill lösa, beskriva vad lösningen behöver klara av och sätta ramar för leverans, kvalitet och samarbete. Målet är inte att låsa varje detalj från start, utan att ge leverantörer tillräckligt underlag för jämförbara och relevanta förslag. Två motpoler beskrivs som vanliga fel: en för vag kravspec gör att leverantörerna tolkar uppdraget helt olika, medan en för detaljerad låser lösningen innan man förstått vad som faktiskt är viktigt. Enligt Fiive ökar kostnaden för att rätta missförstånd och tvetydigheter dramatiskt ju längre in i projektet man kommer – det som tar en timme att klargöra i kravspecen kan kräva veckor av omarbetning om det upptäcks först i slutfasen.

Nyckeldata från svensk reglering och praxis

Krav, önskemål och gråzonen däremellan

I upphandlingssammanhang är kravspecifikationen – eller den tekniska specifikationen – det avsnitt i upphandlingsdokumenten där du ställer krav på själva upphandlingsföremålet, det vill säga varan, tjänsten eller byggentreprenaden. Upphandlingsmyndigheten konstaterar att den upphandlande organisationen har stor frihet att formulera kraven själv, och att hur de formuleras beror på vad som ska upphandlas och syftet med upphandlingen.

Ett obligatoriskt krav är något anbudet måste uppfylla för att alls komma i fråga; ett önskemål vägs i stället in när anbuden jämförs mot varandra. Upphandlingsmyndigheten lyfter frågan i rubrikform: ska kraven formuleras som obligatoriska krav eller som tilldelningskriterier? Valet avgör om en egenskap fungerar som ett filter som sorterar bort anbud, eller som en kvalitetsparameter som poängsätts. En tumregel följer av uppdelningen: under rubriken obligatoriska krav ska bara sådant stå som leverantören entydigt kan svara ja eller nej på, och som ni är beredda att förkasta ett anbud på om det saknas.

Gråzonerna uppstår oftast när en punkt kan läsas både som ett måste och som en fördel. Fiive ger ett typiskt exempel: en kravspec som säger att systemet ska "hantera kunder" men aldrig specificerar att en kund kan ha flera leveransadresser. Det är en mening att reda ut i förväg. Upptäcks det först när gränssnitt, databas och integrationer redan är byggda kring antagandet om en adress per kund, blir det i stället en omarbetning som berör flera delar av systemet samtidigt. Frågan om kunden har flera leveransadresser är antingen ett krav – systemet måste stödja flera adresser per kund – eller inget krav alls. Den blir ett problem bara så länge den lämnas oskriven.

Utgå från problem, mål och användare – inte från lösningen

Fiive rekommenderar att arbetet börjar med nuläget och affärsproblemet, därefter användare och de viktigaste arbetsflödena, och först därefter de viktigaste funktionella kraven. Ordningen är inte kosmetisk: den tvingar fram ett svar på varför varje punkt finns med, vilket är samma upplysning som avgör om punkten hör hemma bland kraven eller bland önskemålen. En punkt som inte kan kopplas till problemet, en målgrupp eller ett arbetsflöde har inget stöd i bakgrunden.

Upphandlingsmyndigheten skiljer på två sätt att formulera krav. Detaljkrav anger detaljerade krav på varans egenskaper eller hur tjänsten ska utföras, och förutsätter att den upphandlande organisationen har djup kunskap om varan, tjänsten eller byggentreprenaden för att nå ett lyckat resultat. Funktionskrav beskriver i stället vad som ska uppnås, inte hur något ska uppnås, och ger leverantören större utrymme att använda sin yrkeskunskap och kreativitet. Myndigheten understryker att man även utan en detaljerad beskrivning av tillvägagångssättet bör precisera vilket resultat som ska uppnås, och att funktionskrav ofta kopplas till mål och mäts som önskade effekter och resultat.

Tyngdpunkten varierar med vad som upphandlas. Enligt Fiive väger integrationskrav, datamigrering och roller/behörigheter ofta tyngre i en kravspecifikation för affärssystem, medan ett skräddarsytt utvecklingsprojekt lägger mer vikt vid användarflöden och prioritering av funktioner. En formulering om vilken effekt som ska uppnås – exempelvis kortare handläggningstid – pekar ut vad som ska mätas och lämnar lösningen öppen. En formulering om en specifik skärmbild eller ett specifikt menyval låser i stället ett tillvägagångssätt innan problemet är färdigformulerat, och bör därför prövas mot om den går att skriva om som funktionskrav.

Sorteringsfrågor som skiljer måste från vill

Gå igenom utkastet punkt för punkt och ställ samma frågor innan något får stå kvar som obligatoriskt krav. Behövs punkten för att lösa det affärsproblem som beskrivs i bakgrunden? Påverkar den en av de angivna målgrupperna eller ett av de viktigaste arbetsflödena? Är den nödvändig för en integration eller en datakälla, för ett säkerhets- eller compliancekrav, eller för drift, support och vidareutveckling? Om svaret är nej på alla dessa frågor är punkten inte ett krav – behandla den då som önskemål eller som utvärderingskriterium i stället för att stryka den.

Integrations- och driftfrågorna är särskilt viktiga att ställa, eftersom Fiive listar integrationskrav och datakällor, säkerhets- och compliancekrav samt krav på drift, support och vidareutveckling som egna avsnitt i kravspecen. Det är områden där en utelämnad punkt inte bara blir en besvikelse hos en användare, utan kan göra lösningen oanvändbar i produktion.

Ställ också frågan om form: beskriver punkten ett resultat eller ett tillvägagångssätt? Upphandlingsmyndighetens uppdelning mellan funktionskrav och detaljkrav gör frågan konkret – ett funktionskrav som anger vad som ska uppnås kan stå kvar som krav, medan ett detaljkrav som låser hur något ska göras bör motiveras med att ni faktiskt har den djupkunskap som krävs för att detaljstyra.

Slutligen: ska punkten vara ett obligatoriskt krav eller ett tilldelningskriterium? Upphandlingsmyndigheten ställer frågan explicit, och valet får direkta konsekvenser. Lägger ni för mycket i de obligatoriska kraven riskerar anbud att sorteras bort på detaljer som egentligen var önskemål; lägger ni för mycket i utvärderingen blir jämförelsen inte längre ett svar på om lösningen alls klarar grundkraven.

Märk upp och formulera så att skillnaden blir synlig

Låt de två kategorierna vara åtskilda i dokumentet. Fiives innehållslista för en kravspec för mjukvaruutveckling fungerar som skelett: bakgrund och affärsmål, vilket problem som ska lösas, målgrupper och användare, viktigaste funktionella krav, integrationskrav och datakällor, säkerhets- och compliancekrav, krav på drift, support och vidareutveckling, projektets ramar för tid, budget och arbetssätt, samt hur anbud ska utvärderas. Samma struktur beskrivs fungera oavsett om ni upphandlar ett nytt affärssystem, en skräddarsydd applikation eller en integration.

De obligatoriska kraven hör hemma i kravavsnittet, formulerade så att ett anbud antingen uppfyller dem eller inte. Önskemålen hör hemma i utvärderingsavsnittet, där de fungerar som tilldelningskriterier och kan viktas mot varandra. Märk upp varje punkt med vilken kategori den tillhör, så att samma egenskap inte förekommer i båda avsnitten med olika status.

Koppla funktionskrav till mål och effekter. Upphandlingsmyndigheten konstaterar att funktionskrav ofta kopplas till mål och mäts som önskade effekter och resultat; gör den kopplingen synlig i dokumentet genom att varje funktionskrav refererar till det mål eller arbetsflöde det ska bidra till. Då syns det direkt vilka krav som påverkas om ett mål ändras.

Används standarder som krav gäller två formalia från Upphandlingsmyndigheten: kravet måste följas av orden "eller likvärdigt", och det bör framgå av upphandlingsdokumenten att bevis som styrker likvärdighet ska bifogas anbudet. Myndigheten hänvisar också till ett ställningstagande från Konkurrensverket som publicerades i juli 2024: det är inte tillåtet att hänvisa till standarder som inte finns kostnadsfritt tillgängliga för leverantören. Ställningstagandet är inte i sig rättsligt bindande, men det påverkar hur en standardhänvisning bör utformas.

Kvalitetssäkra kravspecen före upphandling

Ett krav är verifierbart när det går att i efterhand avgöra om det är uppfyllt. Funktionskrav underlättar det arbetet eftersom de preciserar vilket resultat som ska uppnås och kan mätas som önskade effekter och resultat, enligt Upphandlingsmyndigheten. Formulera därför varje krav med ett resultat som går att kontrollera vid leverans, och varje önskemål med en egenskap som går att jämföra mellan anbud.

För vaga formuleringar är den vanligaste fallgropen. Fiives exempel med systemet som ska "hantera kunder" utan att det framgår att en kund kan ha flera leveransadresser visar vad som händer: antagandet byggs in i gränssnitt, databas och integrationer, och rättas först sent genom en omarbetning som berör flera delar av systemet samtidigt. Samma typ av fälla är krav som beskriver en aktivitet i stället för ett resultat.

Den motsatta fallgropen är onödigt låsta detaljer. Upphandlingsmyndigheten konstaterar att detaljerade krav förutsätter djup kunskap om det som upphandlas, medan Fiive pekar på att en för detaljerad kravspec låser lösningen innan man förstått vad som faktiskt är viktigt. Pröva därför varje detaljkrav mot om det beskriver något ni har kunskap och skäl att styra, eller om det lika gärna kan uttryckas som ett funktionskrav.

Dolda krav – punkter som beställaren förutsätter men som aldrig skrivits ned, eller som dyker upp först under en offertgenomgång – upptäcks genom att kravspecen läses igenom av dem som ska använda lösningen och av dem som ska drifta och förvalta den, innan dokumentet går ut som förfrågningsunderlag. Varje punkt som då tillkommer får samma behandling som övriga: obligatoriskt krav eller önskemål.

Kvalitetssäkringen ger effekt på tre ställen. Genesis IT pekar på att kravspecen gör det möjligt att jämföra anbud på ett objektivt sätt och att den är underlag för utveckling och testning. Fiive pekar på att en välformulerad kravspec ger leverantören möjlighet att lägga sitt anbud mer träffsäkert, vilket minskar behovet av säkerhetsmarginaler i prissättningen – och därmed påverkar både jämförbarheten i upphandlingen och kostnadsuppskattningarnas träffsäkerhet.