Kravspecifikation som styr systemvalet: från behov till kravlista

Utgå från verksamhetsbehovet – inte från systemet

Kravspecifikationen tas fram innan systemen jämförs – inte efteråt. Enligt Upphandlingsmyndigheten har en upphandlande organisation stor frihet att själv formulera kraven på det som ska upphandlas. Formuleringen beror på vad som ska upphandlas och på upphandlingens syfte.

I upphandlingsdokumenten kallas avsnittet med krav på upphandlingsföremålet – varan, tjänsten eller byggentreprenaden – ofta kravspecifikation eller teknisk specifikation. Sidan gäller upphandlingar enligt lagen om offentlig upphandling (LOU) och lagen om upphandling inom försörjningssektorerna (LUF).

Arbetet börjar i verksamheten, inte i en produktdemo. Kartlägg processer, roller, beslut och den information som behövs. Formulera vad lösningen ska åstadkomma och översätt först senare till en kravlista.

Utgår man från ett färdigt system anpassas kraven efter det system man redan fastnat för. Jämförelsen mellan alternativ tappar då sitt värde.

Anskaffningens syfte filtrerar vilka krav som är relevanta. Att ersätta ett föråldrat system ställer andra krav än att effektivisera en process, införa självbetjäning för medborgare eller stärka informationssäkerheten.

Skriv ned syftet i några meningar tidigt och pröva varje krav: bidrar det till syftet, eller hör det hemma någon annanstans? Krav utan koppling till verksamhetsbehovet är svåra att prioritera och ännu svårare att verifiera.

En steg-för-steg-guide i hur en kravspecifikation tas fram går från verksamhetsbehov och behovs-/marknadsanalys via kravtyper och obligatoriska krav/önskemål till verifierbara krav och en beslutsmatris. Så styrs systemvalet av kraven.

Behovsanalys och marknadsanalys som första kravfilter

Två analyser underlättar innan kravlistan skrivs: behovsanalys och marknadsanalys. Upphandlingsmyndigheten lyfter fram båda som stöd i kravställningen.

Behovsanalysen beskriver vad verksamheten faktiskt behöver; marknadsanalysen vad som är rimligt att efterfråga och hur marknaden ser ut. Tillsammans ringar de in krav som är realistiska, relevanta och möjliga att ställa.

En behovsanalys dokumenterar typiskt nuvarande arbetssätt och brister, volymer och ärendetyper, berörda system och avtal, nödvändiga integrationer samt beroenden till andra verksamheter. Den ger underlag för att skilja egentliga behov från önskemål som mest handlar om vana vid ett visst gränssnitt.

En marknadsanalys kartlägger vilka typer av lösningar och leverantörer som finns, vanliga lösningsmodeller, standarder som används i branschen och vilka krav marknaden rimligen kan uppfylla. Tidig dialog med marknaden är ett vanligt sätt att skaffa kunskapen utan att binda sig vid en leverantör.

Det leder till färre krav som ingen kan uppfylla och färre krav som är så snäva att de pekar ut en enda lösning.

Upphandlingsmyndigheten hänvisar till DIGG:s stöd för kravställning vid upphandling av data. Stödet kan användas när datahantering ingår i behovs- och marknadsanalysen.

Detaljkrav, funktionskrav eller standarder – välj kravtyp medvetet

Upphandlingsmyndigheten beskriver tre sätt att formulera krav: detaljkrav, funktionskrav och standarder.

Detaljkrav anger detaljerade krav på varans egenskaper eller hur tjänsten ska utföras. Funktionskrav beskriver funktionen – vad som ska uppnås, inte hur.

Standarder kan användas för att göra det enhetligt och tydligt för både upphandlande organisation och leverantör vad en vara eller tjänst innehåller.

Detaljkrav kräver att den upphandlande organisationen har djup kunskap om det som ska köpas för att uppnå ett lyckat slutresultat. De passar när verksamheten vet exakt vilken lösning som behövs, eller när kraven följer av interna beslut och en befintlig teknikmiljö som inte kan ändras. Nackdelen är att de låser lösningen och minskar leverantörens utrymme att föreslå något bättre.

Funktionskrav ger leverantören större utrymme att använda sin yrkeskunskap och kreativitet. Även om tillvägagångssättet inte beskrivs i detalj bör organisationen precisera vilket resultat som ska uppnås, eftersom funktionskrav ofta kopplas till mål och mäts som önskade effekter och resultat.

De är särskilt användbara när flera tekniska lösningar kan nå samma nytta, men ställer högre krav på mätbara mål och fungerande uppföljning.

Standarder kan underlätta och effektivisera vid inköp och upphandling och hjälper organisationer och leverantörer att arbeta strukturerat och enhetligt. Används standarder måste kravet följas av orden ”eller likvärdigt”, och det bör framgå av upphandlingsdokumenten att bevis som styrker likvärdighet ska bifogas anbudet.

Enligt ett ställningstagande från Konkurrensverket från juli 2024 är det inte tillåtet att hänvisa till standarder som inte finns att tillgå kostnadsfritt för leverantören. Ställningstagandet är i sig inte rättsligt bindande.

Ett vanligt arbetssätt är att kombinera kravtyperna: funktionskrav där verksamheten vill ha handlingsfrihet, detaljkrav där gränssnitt eller tekniska förutsättningar måste vara exakt bestämda, och standarder där branschen redan har etablerade referenser.

Namngivna standarder att hänvisa till är EN 301 549 och WCAG 2.1. EN 301 549 bygger på WCAG 2.1.

För offentlig sektor finns DOS-lagen. Den ställer krav på tillgänglighet till digital service som tillhandahålls av en offentlig aktör.

För- och nackdelar med olika kravtyper

Obligatoriska krav och önskemål i två nivåer

Upphandlingsmyndigheten tar upp frågan om kraven ska formuleras som obligatoriska krav eller tilldelningskriterier. Obligatoriska krav måste anbudet uppfylla för att komma ifråga.

Tilldelningskriterier används för att jämföra, vikta och prioritera mellan de anbud som klarar de obligatoriska kraven.

För systemvalet innebär två nivåer att kraven delas i två listor. Den ena innehåller det som måste vara uppfyllt, till exempel krav som följer av verksamhetens lagbundna uppgifter, av befintlig teknisk miljö eller av organisationens säkerhetskrav.

Den andra innehåller sådant som är önskvärt och kan vägas mot pris och andra faktorer.

En vanlig fallgrop är att blanda nivåerna och formulera önskemål som absoluta krav. Det ger ofta få anbud och gör det svårare att argumentera för varför ett visst system valdes. Motsatsen – att göra nästan allt till önskemål – gör jämförelsen godtycklig.

Varje obligatoriskt krav ska kunna motiveras med ett verksamhetsbehov, och varje önskemål ska vara formulerat så att det går att bedöma och vikta på ett någorlunda enhetligt sätt.

DOS-lagen kan göra tillgänglighet till ett obligatoriskt krav för offentliga aktörer. Den gäller webbplatser, mobila applikationer, dokument och digitala tjänster.

Digg har tillsynsansvar enligt DOS-lagen. Tillsynen gäller digital offentlig service.

Kravområden som ofta avgör systemvalet

Vissa kravområden återkommer nästan oavsett vilken typ av system som ska anskaffas, och de är ofta de som avgör valet i slutändan.

Funktion. Beskriv de processer och ärendetyper systemet ska stödja, vilka roller som ska kunna arbeta i det och vilka arbetsflöden som ska kunna genomföras. Funktionskrav passar här eftersom de beskriver vad som ska uppnås och mäts som effekter och resultat.

Integration. Kartlägg vilka system lösningen ska utbyta information med, vilken information som ska utbytas, i vilken riktning och med vilken frekvens. Krav på gränssnitt och format är ofta bland de mest konkreta och avgörande delarna av kravlistan.

Informationssäkerhet och datahantering. Beskriv vilken information som hanteras, hur känslig den är, vem som ska komma åt den och hur den ska lagras och gallras. För offentlig sektor är säker digital kommunikation ett område där kraven behöver preciseras.

DIGG:s ramverk för säker digital kommunikation är namngivet. En standardiserad lösning är plattformen Säker Digital Kommunikation (SDK).

SDK omfattar säkra meddelanden och ett säkert mellanlager. Den anger 24/7 tillgänglighet.

Upphandlingsmyndigheten hänvisar också till DIGG:s stöd för kravställning vid upphandling av data.

Aktörer som bygger lösningar på DIGG:s ramverk för säker digital kommunikation framhåller att säkerhet är en grundförutsättning snarare än en eftertanke, eftersom myndigheter, kommuner och regioner dagligen utbyter stora mängder information.

För den egna kravlistan blir frågan vilka kanaler och vilken spårbarhet som verksamheten behöver, och hur det ska kunna verifieras.

Tillgänglighet och användbarhet. Kraven bör handla om att medarbetare och medborgare med olika förutsättningar ska kunna använda lösningen, och om hur det ska kontrolleras. Formulera kraven så att de går att testa snarare än som allmänna omdömen.

För offentlig sektor styr DOS-lagen. Digg granskar enligt EN 301 549, som bygger på WCAG 2.1.

Under 2025 ska Digg granska 418 webbplatser och 17 mobila applikationer.

Drift, förvaltning och livscykel. Beskriv krav på tillgänglighet, support, uppdateringar, dokumentation, utbildning och vad som händer vid avtalets slut. Även om dessa krav inte handlar om funktioner i systemet är de ofta avgörande för totalkostnaden över tid.

Top 5 avgörande kravområden vid systemval

Formulera verifierbara krav och acceptanskriterier

Ett krav som inte går att verifiera går heller inte att följa upp och blir därmed en källa till tvist i ett senare skede. Utgångspunkten är att varje krav ska kunna besvaras med ett tydligt ja eller nej, eller mätas mot ett angivet värde.

Undvik formuleringar som ”användarvänligt”, ”modernt”, ”flexibelt” och ”hög prestanda” utan att precisera vad de betyder i den här verksamheten. Ersätt dem med beskrivningar av en situation: vilken uppgift ska kunna utföras, av vem, med vilket resultat och inom vilken tid.

Om ett värde anges bör det också framgå hur det ska mätas och i vilken miljö.

Koppla varje krav till ett eller flera acceptanskriterier som beskriver vad som ska vara uppfyllt för att kravet ska anses uppfyllt. Kriterierna blir underlag för acceptanstester vid införandet och för regressionstester när systemet förändras över tid.

I systemnära utvecklings- och verifieringsarbete är systemövergripande verifiering, acceptans- och regressionstester samt analys av avvikelser återkommande arbetsuppgifter. Det speglar att verifieringen måste planeras redan när kraven skrivs.

Bestäm också i förväg vem som verifierar, med vilken metod och med vilket underlag. Vissa krav verifieras genom tester i en testmiljö, andra genom granskning av dokumentation, certifikat eller genom referenser.

Att tidigt bestämma verifieringsmetod tvingar fram krav som är tillräckligt konkreta – och synliggör krav som egentligen inte går att kontrollera.

Exempel på verifierbart krav: Webbplatsen ska uppfylla WCAG 2.1 enligt EN 301 549. Acceptanskriterium: Digg granskar enligt sin tillsynsmanual.

Exempel på verifierbart krav: Lösningen ska skicka säkra meddelanden via DIGG:s ramverk för säker digital kommunikation. Acceptanskriterium: Säkra meddelanden och säkert mellanlager verifieras.

Ett mätvärde kan vara 24/7 tillgänglighet.

Verifieringskontroller för krav

Använd kravlistan som beslutsunderlag

När kraven är framtagna, uppdelade i obligatoriska krav och önskemål samt försedda med acceptanskriterier, fungerar listan som det underlag som systemvalet vilar på. Den gör det möjligt att jämföra alternativ på samma grunder i stället för att jämföra demonstrationer och intryck.

Ett praktiskt arbetssätt är att bygga en matris där varje krav är en rad och varje kandidat är en kolumn. Obligatoriska krav besvaras med uppfyllt eller inte uppfyllt, och önskemålen ges poäng enligt en viktning som bestäms i förväg.

Viktningen bör sättas innan anbuden eller systemdemonstrationerna utvärderas, annars är risken stor att den anpassas efter det alternativ man redan föredrar.

Spårbarhet är en del av beslutsunderlaget. Varje krav bör kunna härledas till ett verksamhetsbehov eller ett syfte, och varje avvägning bör dokumenteras: varför ett krav blev obligatoriskt, varför ett annat blev ett önskemål, och vad man valde bort.

Det gör beslutet begripligt för dem som inte deltog i arbetet och hållbart när någon frågar varför just detta system upphandlades.

Håll kravlistan levande under upphandlingens gång. Om förutsättningarna ändras bör det framgå av dokumentationen vad som ändrades och varför.

Kravlistan är också grunden för att senare avgöra om det valda systemet levererar det verksamheten behöver.

Matrisen bör minst visa krav, kravtyp, om kravet är obligatoriskt eller ett önskemål, acceptanskriterium och verifieringsmetod. Då bedöms varje kandidat mot samma underlag.