Kravspecifikation
Så prioriterar du krav med MoSCoW i systemvalsprojekt
Riksrevisionen publicerade den 29 april 2025 rapporten Statliga strategiska digitaliseringsprojekt – stora gemensamma utmaningar (RiR 2025:8).
Varför MoSCoW gör skillnad i systemvalsprojekt
Riksrevisionen publicerade den 29 april 2025 rapporten Statliga strategiska digitaliseringsprojekt – stora gemensamma utmaningar (RiR 2025:8). Granskningen omfattar 1 094 strategiska digitaliseringsprojekt som drivits av 136 statliga myndigheter under 2013–2024, med en samlad budget på cirka 40 miljarder kronor. Riksrevisionens övergripande slutsats är att det finns flera effektivitetsbrister: myndigheterna har återkommande problem med att leverera resultat inom utsatt tid och budget, ofta på grund av brist på it-kompetens och bristande kravställning.
Av de 722 projekt som var avslutade när granskningen gjordes hade minst 120 inte fullt ut uppnått sina mål och syften. 31 projekt hade avbrutits utan att leverera de avsedda resultaten och 86 hade levererat en it-lösning som inte helt motsvarade de uppsatta målen, enligt myndigheternas egna utvärderingar. De avbrutna projekten hade sammanlagt kostat 1,6 miljarder kronor, och merparten var stora och dyra projekt vid myndigheter med samhällsviktig funktion, såsom Trafikverket, Boverket, Lantmäteriet och Svenska kraftnät.
När kraven är otydliga finns inget underlag för att avgöra vilka funktioner som är avgörande och vilka som är önskemål. MoSCoW används för att organisera och prioritera projektkrav i Must have, Should have, Could have och Won't have. Enligt metodbeskrivningar hjälper det till att identifiera vad som måste göras för att projektet ska lyckas och vad som kan vänta. I ett systemvalsprojekt blir den sorteringen det som skiljer ska-kraven från önskemålen i utvärderingen av leverantörer och system.
Statistik från Riksrevisionens granskning (2025)
MoSCoW-metodens fyra nivåer – och vad de betyder i praktiken
MoSCoW är en akronym för fyra prioriteringskategorier. Must have (Måste ha) är krav som är väsentliga och måste uppfyllas; de kan inte förhandlas bort, eftersom underlåtenhet att uppfylla dem leder till att projektet misslyckas. Should have (Bör ha) är viktiga men inte väsentliga för projektet; om de saknas kan det skapa svårigheter, men det äventyrar inte projektet. Could have (Kan ha) är önskvärda men inte nödvändiga krav som kan tas med om tid och resurser finns – att ta bort dem påverkar inte projektets framgång nämnvärt. Won't have (Kommer inte att ha) är krav som inte är planerade för genomförande i aktuell fas eller projekt; de skjuts vanligtvis upp eller utesluts.
Skillnaden mellan nivåerna handlar om kritikalitet och flexibilitet. Must-krav är obligatoriska för leveransen och måste finnas för att projektet över huvud taget ska kunna röra sig framåt. Should-krav är nästintill obligatoriska för ett framgångsrikt projekt men har viss flexibilitet i utförandet eller tidslinjen. Could-krav är icke-kritiska och kan bidra till den övergripande kvaliteten utan att vara avgörande för huvudmålet. Won't-krav är sådant som definitivt inte ska implementeras i aktuell iteration eller fas – exempelvis funktioner som är för kostsamma att utveckla eller inte ger tillräckligt värde för att motivera sin inkludering.
Metoden grundades av Dai Clegg i början av 1990-talet och används ofta tillsammans med DSDM (Dynamic System Development Method). Den innehåller tre tydliga prioriteringsnivåer och täcker dessutom de krav som i slutändan inte alls kommer att bli inkluderade i den nuvarande leveransen eller i projektet – vilket gör det möjligt att tydligt komma överens om vilka krav som ska inkluderas eller exkluderas.
Så genomför du en MoSCoW-analys steg för steg
- Samla in krav och önskemål från alla berörda parter. De kan komma från verksamheten, användarna, it-förvaltningen och ledningen. Projektledarens uppgift är att få kontroll över vilka områden som är viktigast för såväl kunden som organisationen. Utgå från behovet hos kunder eller användarna – en prioritering som inte bygger på faktiska behov blir godtycklig.
- Formulera och gruppera kraven så att varje krav går att bedöma för sig. Slå ihop dubbletter, dela upp sammansatta krav som blandar ett måste med ett önskemål, och skriv varje krav så att det framgår vad systemet ska kunna göra och för vem. Ett krav som innehåller flera olika funktioner hamnar ofta fel i prioriteringen, eftersom delarna har olika kritikalitet.
- Fördela kraven nivå för nivå. Börja med den mest kritiska delen – de krav som måste uppfyllas för att projektet ska lyckas – och placera dem i Must have. Gå därefter vidare till de krav som är viktiga men inte kritiska för projektets framgång och placera dem i Should have. Krav som kan vänta hamnar i Could have, och krav som helt enkelt inte kan eller ska hanteras i projektet placeras i Won't have.
- Förankra prioriteringarna med intressenterna. Metoden ger möjligheten att komma överens om vilka prioriteringar och krav som ska vara inkluderade eller exkluderade inför den kommande leveransen. Gå igenom listan med dem som ska leva med systemet och med dem som finansierar införandet, och dokumentera både nivån och skälet till att kravet ligger där. Ett krav utan motivering är svårt att flytta senare, när förutsättningarna ändras.
Så genomför du en MoSCoW-analys – steg för steg
- Samla in krav från alla parterInklusive användare, IT-förvaltning, ledning och verksamhetsansvariga.
- Formulera och gruppera kravenDel upp dubbeltskrivna eller sammansatta krav. Var konkret om vad systemet ska kunna göra.
- Fördela kraven per nivåBörja med Must, sedan Should, Could, och avsluta med Won't.
- Förankra prioriteringarna med intressenterGå igenom listan med beställare, användare och finansierare. Dokumentera varje nivå och skäl.
Kontrollfrågor som skiljer Must från Should och Could
Den mest användbara frågan är: Vad händer om X inte finns? Om svaret är att leveransen eller projektet inte fungerar över huvud taget är kravet ett Must have. Om svaret i stället är att det blir besvärligt, men verksamheten kan fortsätta, är kravet ett Should have.
Komplettera med dessa frågor per krav:
– Är kravet förhandlingsbart? Går kravet att diskutera eller byta ut mot en enklare lösning är det inte ett Must.
– Klarar projektet sig utan kravet? Om ja, men lösningen blir besvärlig, är det inte ett Must.
– Kan kravet skjutas upp utan att projektmålet äventyras? Om ja, hör det till Could.
– Är kravet för kostsamt att utveckla i förhållande till värdet? Då hör det hemma i Won't have.
– Ska kravet hanteras i den här fasen eller iterationen? Om nej: för det till Won't have och notera att det kan bli aktuellt i en senare fas.
Vanliga fallgropar – och så undviker du dem
Allt hamnar i Must have. Om varje krav beskrivs som oumbärligt upphör prioriteringen att vara en prioritering, och utvärderingen av system tappar sitt viktigaste verktyg: att skilja det kritiska från det mindre viktiga. Motverka det genom att kräva ett konkret svar på frågan vad som händer om kravet inte uppfylls, och genom att sätta ett tak för hur stor andel av kraven som får ligga i Must. Tvingas ni välja bort något, har ni prioriterat.
Won't have blir tom eller otydlig. Kategorin fyller en egen funktion: den dokumenterar vad som inte ska hanteras i projektet, och den är det som gör det möjligt att komma överens om vilka krav som exkluderas inför leveransen. Lämnas den tom, försvinner den överenskommelsen och kraven återkommer senare i projektet utan beslut.
Prioriteringen förankras inte. Om nivåerna bara sätts internt av projektgruppen uppstår diskussioner i efterhand om varför ett visst krav inte levererades. Gå igenom listan med beställare, användare och it-förvaltning innan den ligger till grund för systemvalet, och dokumentera skälen bakom varje nivå.
Kraven formuleras för vagt för att kunna bedömas. Ett krav som "bättre rapportering" kan varken prioriteras eller utvärderas. Dela upp det i konkreta funktioner och sätt nivå på varje del.
MoSCoW som underlag i systemvalsprocessen
Använd de fyra nivåerna som fyra olika roller i utvärderingen. Must-kraven är ska-kraven: de ska besvaras med ja eller nej av varje system och leverantör, och ett system som inte klarar dem faller bort eller kräver ett medvetet beslut om avvikelse. Should-kraven kan viktas och jämföras mellan system. Could-kraven används för att skilja system som ligger nära varandra åt när ska-kraven redan är uppfyllda. Won't-kraven ska inte finnas med i utvärderingen.
Strukturera kravdokumentet så att varje krav har samma uppbyggnad: en tydlig beskrivning, en MoSCoW-nivå och en motivering till nivån. Då kan samma lista skickas till alla leverantörer och svaren jämföras på lika villkor, i stället för att varje leverantör svarar på olika versioner av behovet.
Hantera avvikelser genom att gå tillbaka till nivån, inte genom att förhandla bort kravet i tysthet. Om ett system saknar ett Must-krav behöver ni avgöra om det går att uppfylla på annat sätt, om kravet i själva verket var ett Should-krav, eller om systemet ska väljas bort. Om ett system saknar ett Could-krav är det oftast utan betydelse för valet. Poängen är att avvikelsen blir ett medvetet beslut som kan kopplas till projektets huvudmål – inte en detalj som glider igenom.
Använd också Won't-listan aktivt i systemvalet. Den talar om för leverantörer och interna intressenter vad som inte ska lösas nu, vilket minskar risken för att krav som medvetet skjutits upp dyker upp igen sent i upphandlingen och driver kostnader och tid.
Exempel på hur krav kan prioriteras
Nedanstående exempel är illustrativa och visar principen: nivån bestäms av vad som händer om kravet inte uppfylls, och formuleringen avgör vad som faktiskt efterfrågas i systemvalet.
Must have: "Systemet ska hantera behörigheter så att användare bara kommer åt de uppgifter som hör till deras roll." Utan detta kan verksamheten inte bedrivas på ett godtagbart sätt – kravet är obligatoriskt och inte förhandlingsbart. Must have: "Systemet ska kunna ta emot de uppgifter som verksamheten i dag registrerar, utan manuell dubbelregistrering." Saknas detta faller själva nyttan med införandet.
Should have: "Systemet bör kunna skicka automatiska aviseringar när en uppgift närmar sig sin deadline." Det gör arbetet enklare och är nästintill obligatoriskt för ett bra resultat, men bristen skapar bara svårigheter – verksamheten kan fortsätta med manuella rutiner.
Could have: "Systemet kan erbjuda en avancerad rapportbyggare där användaren själv kombinerar urvalskriterier." Det är önskvärt och bidrar till kvaliteten, men tas med bara om tid och resurser finns, och borttagandet påverkar inte projektets framgång nämnvärt. Won't have: "Systemet ska stödja samtliga historiska filformat från tidigare system." Det är för kostsamt att utveckla i förhållande till värdet och skjuts upp till en senare fas.
Lägg märke till hur formuleringen styr vad som efterfrågas. "Systemet ska kunna exportera rapporter" är ett brett krav som nästan alla leverantörer kan svara ja på. "Systemet ska kunna exportera rapporten till en fil som kan öppnas i verksamhetens kalkylprogram" är ett krav som kan bedömas, prioriteras och följas upp. Ett krav du inte kan avgöra om det är uppfyllt eller inte går heller inte att placera på rätt MoSCoW-nivå.
Håll prioriteringen levande genom hela projektet
MoSCoW ger fokus: metoden hjälper till att identifiera vad som måste göras för att projektet ska lyckas och vad som kan vänta till senare, och den minimerar risken att tid och pengar läggs på irrelevanta krav. Men en prioritering är inte ett dokument som skrivs en gång. När tid, budget eller förutsättningar förändras behöver nivåerna ses över igen – krav kan flyttas mellan Must, Should och Could, och sådant som ligger i Won't kan bli aktuellt i en senare fas.
Uppföljningen är också en egen riskpunkt. Riksrevisionens granskning konstaterar att en majoritet av de genomförda strategiska digitaliseringsprojekten inte hade utvärderats, vilket försvårar en samlad bedömning av måluppfyllelsen, och att regeringens styrning brister när det gäller uppföljning och tvärsektoriell samordning. Sätt därför rutiner för att gå igenom kravlistan vid beslutspunkter i systemvalsprojektet: vilka Must-krav är uppfyllda, vilka avvikelser finns, och vilka krav har flyttats sedan förra gången. Då fungerar prioriteringen både som urval under utvärderingen och som underlag för att bedöma om projektet nådde sina mål.
