En kravspecifikation som börjar i verkliga behov – inte i en tänkt lösning – ökar träffsäkerheten, konkurrensen i upphandling och chanserna att skapa användbara, lagliga och kostnadseffektiva digitala tjänster. EU:s upphandlingsregler och svenska vägledningar rekommenderar uttryckligen att tekniska specifikationer formuleras som funktions- och prestationskrav (vad som ska uppnås) i stället för detaljerade lösningskrav (hur det ska göras). Samtidigt ska krav vara spårbara till identifierade användarbehov och mätbara genom tydliga acceptanskriterier.
Varför behovsbaserad kravställning?
- Större konkurrens och bättre lösningar. Funktionskrav bjuder in fler leverantörer och skapar utrymme för innovation – ett uttryckligt syfte i EU-rätten och svensk vägledning.
- Högre användbarhet och lägre risk. ISO 9241-210 kräver kontinuerlig användarinvolvering och användarcentrerad utvärdering. När kraven härleds från dokumenterade behov blir de testbara mot verklig användning.
- Efterlevnad och inkludering från start. Offentliga e-tjänster ska uppfylla tillgänglighetskrav. Standard EN 301 549 används i Europa för att specificera och verifiera sådana krav i upphandling.
Rättslig och strategisk ram i korthet
- Direktiv 2014/24/EU, artikel 42. Tekniska specifikationer ska främja likvärdig åtkomst och bör formuleras som prestanda- eller funktionskrav. Detta har nyligen bekräftats i EU-domstolens praxis.
- Upphandlingsmyndigheten. Rekommenderar funktionskrav när det går, och beskriver skillnaden mellan detaljkrav (hur) och funktionskrav (vad).
- Tillgänglighet. EN 301 549 harmoniserar hur tillgänglighet specificeras och prövas i upphandling av ICT – kopplat till webbtillgänglighetsdirektivet (i Sverige: DOS-lagen).
- Behovsdriven utveckling & nyttorealisering. Svensk vägledning betonar spårbarhet från behov till krav och vidare till uppsatta nyttor och uppföljning.
Från behov till krav: en spårbar kedja
- Behovsuttalanden (user needs). Formulera vem som har vilket behov och varför.
- User stories (för genomförande): Som [användare] behöver jag [mål] så att [nytta] – kopplat till acceptanskriterier. GOV.UK beskriver format och hur stories kopplas till behov för spårbarhet.
- Krav i upphandling/kontrakt. Översätt prioriterade behov/stories till funktions-, prestanda- och efterlevnadskrav med verifierbara mätpunkter (se mall nedan).
- Test & verifiering. Sätt mätmetoder i kravspecifikationen (t.ex. uppgiftsbaserade tester, SUS, WCAG-revision, lasttest), och koppla dem till acceptanskriterierna.
Så skriver du krav som utgår från behov (steg för steg)
Steg 1 — Strukturera kravbilden
Dela upp specifikationen i:
- Funktionskrav (VAD) – användarflöden och förmågor som ska finnas.
- Prestandakrav – nivåer för t.ex. svarstid, tillgänglighet (SLA), genomströmning.
- Användbarhet & tillgänglighet – mätbara kriterier (t.ex. uppgiftsframgång ≥ 90 % i kritiskt flöde; WCAG 2.2 AA enligt EN 301 549).
- Säkerhet & integritet – roller/behörigheter, loggning, DPIA-krav (vid behov).
- Interoperabilitet & data – gränssnitt, standarder, export/import.
- Drift & förvaltning – versionsstöd, backup, incidentprocess, utbildning.
Upphandlingsmyndigheten bekräftar att kravdelen i upphandlingsdokumenten ofta kallas kravspecifikation/teknisk specifikation och att du har frihet att välja formulering – välj därför funktionskrav där det är möjligt.
Steg 2 — Skriv funktionskrav i prestationsform
Mindre bra (lösningslåsning):
Tjänsten ska använda [specificerad teknik] för att validera adress.
Bättre (funktions-/prestationskrav):
Användarens adress ska valideras automatiskt mot en tillförlitlig källa innan insändning. Fel ska återkopplas i samma steg utan sidladdning. Verifiering: 10/10 felinmatningar ger vägledning enligt testprotokoll.
Motivet: fler leverantörer kan konkurrera och du mäter utfall, inte teknikval – i linje med artikel 42.
Steg 3 — Koppla varje krav till acceptanskriterier
Använd klarspråk och teknikneutrala kriterier. GOV.UK visar god praxis för acceptanskriterier som gränssätter vad som ska uppnås och hur det testas, utan implementationstermer.
Exempel (utdrag):
- AC-1 (Task success): Minst 90 % av representativa användare slutför ansökan utan stöd i användningstest.
- AC-2 (Tid): Median tid till slutförd uppgift ≤ 6 min (p90 ≤ 10 min).
- AC-3 (WCAG): Alla kritiska flöden uppfyller WCAG 2.2 nivå AA enligt EN 301 549 Annex A testmetod.
Steg 4 — Märk upp kravens “styrka” och prövning
- Obligatoriskt krav (ska-krav). Måste vara uppfyllt för att anbud ska antas. Konkurrensverket förklarar begreppet “obligatoriska krav/’ska-krav’”.
- Bör-krav / tilldelningskriterier. Poängsätts vid utvärdering; Upphandlingsmyndigheten beskriver hur “bör-krav” ofta fungerar som tilldelningskriterier. Ange hur de poängsätts.
- Kontraktsvillkor. Ska uppfyllas vid fullgörande (inte nödvändigtvis vid anbud). DIGG ger exempel på tidsättning av krav (vid anbud, vid driftsättning, senare).
Steg 5 — Specificera tillgänglighet korrekt
Hänvisa till EN 301 549:2021 och beskriv prövningsmetod (t.ex. WCAG-granskning + manuell hjälpmedelstest) samt redovisning (tillgänglighetsredogörelse). Detta är det säkra sättet att operationalisera DOS-kraven i upphandling.
Steg 6 — Lägg in spårbarhet och referenser
GOV.UK rekommenderar att varje user story/krav spåras till sitt underliggande behov. Använd en enkel spårbarhetsmatris: Behov → Story → Krav → Test/AC → Nyttomål.
Exempel på kravtexter (mall att anpassa)
A. Funktionskrav (ansökningsflöde)
- Systemet ska möjliggöra att en användare på egen hand kan påbörja, pausa och återuppta en pågående ansökan.
- Fel som hindrar slutförande ska förklaras i direkt anslutning till fältet med förslag till åtgärd.
Prövning: Modererat användningstest enligt protokoll (n=6 per målgrupp). AC: Task success ≥ 90 %, p90 tid ≤ 10 min.
B. Prestanda
- API-svar i kritiskt steg ska ha median < 500 ms (p95 < 1 000 ms) under normal last.
Prövning: Lasttest enligt bilaga.
C. Tillgänglighet
- Leveransen ska uppfylla EN 301 549:2021 inkl. WCAG 2.2 nivå AA för webbdelar.
Prövning: Dokumenterad granskning + manuell skärmläsartest (NVDA/VoiceOver).
D. Spårbarhet
- Varje krav postas med referens till behov-ID och acceptanskriterier. Leverantören ska föra krav-till-test-matris.
E. Kontraktsvillkor (exempel)
- Senast vid driftsättning: offentlig tillgänglighetsredogörelse och kontaktväg för hinder.
- Inom 3 månader: första service-KPI (completion, satisfaction, cost per transaction, digital take-up) rapporteras kvartalsvis.
Vanliga fallgropar – och hur du undviker dem
- Lösningslåsning. Undvik fabrikat/teknik i kravtexten om det inte är objektivt motiverat; formulera funktions-/prestationskrav.
- Otestbara krav. Skriv alltid acceptanskriterier och prövningsmetod.
- Tillgänglighet i efterhand. Specificera EN 301 549 och beskriv test/rapportering i själva kravspecifikationen.
- Ingen spårbarhet till behov. Använd behov→krav→test-matris enligt Service Manual.
- Oklara “bör-krav”. Definiera poängsättning och bevis.
Checklista: kvalitetssäkra din kravspecifikation
- Kraven är funktions-/prestationsbaserade där möjligt (artikel 42).
- Varje krav har acceptanskriterier och prövningsmetod.
- Tillgänglighet: EN 301 549 + WCAG 2.2 AA är specificerade med test.
- Spårbarhet: behov→story→krav→test dokumenterad.
- Obligatoriska vs bör-krav är tydligt markerade, inkl. tidpunkt då de ska vara uppfyllda.
- Nyttorealisering: koppling till mål/KPI och rapporteringskrav i kontrakt.
Fördjupning och stöd
- Upphandlingsmyndigheten: funktionskrav, kravtyper, upphandlingsdokument.
- EU 2014/24/EU art. 42 & praxis: funktions-/prestandakrav ökar konkurrens och neutralitet.
- EN 301 549 (2021): harmoniserad standard för tillgänglighet vid upphandling.
- ISO 9241-210 (2019): principer för människocentrerad utveckling.
- Digitaliseringsguiden/DIGG: behovsdriven utveckling och nyttorealisering i offentlig sektor.
- GOV.UK Service Manual: user needs, user stories, acceptanskriterier och spårbarhet.