Kravspecifikation för affärssystem: vad bör den innehålla?

Syfte och avgränsning: vad kravspecifikationen ska styra

En kravspecifikation för affärssystem har tre uppgifter: översätta verksamhetens behov till verifierbara krav, ge köpare och leverantör ett gemensamt språk och dra en tydlig gräns för vad som ingår i affärssystemet. Enligt SIS skapar standarder enhetliga och transparenta rutiner som parterna kan enas kring; de underlättar upphandling och avtal eftersom köpare och leverantörer talar samma språk. Kravspecifikationen har samma roll: båda parter mäts mot den vid acceptans och i tvist.

Avgränsa utifrån vad ett affärssystem faktiskt är. Branschguider beskriver det som integrerad programvara för ekonomi, order, lager, inköp och rapportering i ett sammanhållet system, byggt kring en gemensam databas, automatiserade affärsflöden och realtidsbaserad uppföljning; på engelska används ERP (Enterprise Resource Planning). Skriv ut vilka processer som ska ligga i affärssystemet, vilka system som blir kvar vid sidan om och vilka integrationer som krävs mellan dem. Gränsdragningen mot ekonomisystem är särskilt relevant: ekonomisystem hanterar bokföring, fakturering och redovisning, medan affärssystem täcker hela verksamheten.

Nuläge och processer som kravbilden vilar på

Kartlägg innan kraven skrivs. Beskriv hur ni arbetar i dag – flöden för ekonomi, order, lager och projekt – och identifiera vad som fungerar bra och vad som behöver förbättras. Enligt affärssystemskonsulten Pector ger det en tydlig bild av vilka krav ni ska ställa på ett nytt system.

Typiska symptom: order i ett system, lager i ett annat och ekonomi i ett tredje, med manuell synk ofta via Excel. Enligt Confects guide ger det felaktiga saldon, försenad fakturering och osäkra beslutsunderlag. Dokumentera per flöde vilka steg som utförs, i vilket system, av vem, hur många gånger samma uppgift registreras, var data lagras och var avbrott eller manuella överföringar uppstår. Fastställ samtidigt målen för förbättringen – till exempel kortare ledtid från order till faktura, färre manuella registreringar eller snabbare rapportframtagning – så att de senare kan kopplas till enskilda krav och prioriteringar.

Funktionella krav: processer och dataflöden

Skriv funktionella krav per verksamhetsprocess. Enligt Pector hanterar ett modernt affärssystem ekonomi och redovisning, fakturering, inköp och orderhantering samt lager och logistik, och många lösningar har inbyggd rapportering och realtidsanalys. I projektbaserad verksamhet är det också vanligt att tidrapportering, resursplanering och projektuppföljning ligger i samma system, vilket minskar behovet av parallella verktyg.

Formulera kraven som beteenden i flödet, inte som funktionsnamn. Typiska exempel på den nivån: ekonomin uppdateras automatiskt när en order bekräftas, lagersaldot justeras i realtid och inköpsbehov genereras utan manuell hantering – samtliga beskrivningar av hur ett affärssystem arbetar enligt Confects guide. Komplettera med krav på vad som ska kunna registreras, ändras, krediteras och rättas, vem som får göra det och vilka kontroller som ska slå till.

Dataflöden och integrationer hör till samma avsnitt. Ställ krav på att masterdata som kunder, artiklar och leverantörer har en ägande källa, vilka filformat och gränssnitt utbytet ska ske genom, hur ofta utbytet ska ske och vad som händer vid överföringsfel. Specificera även rapporteringen: vilka rapporter som krävs, vilka data de bygger på, uppdateringsfrekvens och vilka roller som ska kunna ta del av dem.

Icke-funktionella krav: användbarhet, säkerhet, drift och flexibilitet

Icke-funktionella krav avgör ofta om systemet fungerar i vardagen. Uppsatsen om vilka krav som bör beaktas i ett affärssystem (G. Andersson, 2023) tar upp användbarhet och användarvänlighet, säkerhet, drift och underhåll, flexibilitet samt incidenthantering. Sådana områden är lätta att förbise när fokus ligger på funktionslistor och bör därför skrivas lika konkret som de funktionella kraven.

Formulera användbarhet mätbart: tidsåtgång eller antal steg för de vanligaste arbetsuppgifterna per roll, krav på utbildning vid införandet och krav på att vanliga uppgifter ska kunna utföras utan att byta system. Ange prestanda och tillgänglighet som svarstider för definierade transaktioner, tillåten avbrottstid och hur avbrott ska meddelas.

Driftkrav följer av leveransformen. Enligt Pector uppdateras molnbaserade lösningar (SaaS) automatiskt och har en skalbar kostnadsmodell baserad på antal användare, medan on-premise-system installeras lokalt. Det ger olika krav: för SaaS krävs uppdateringsfönster, versionshantering och hur era data lämnas ut vid avslut; för on-premise krävs egen driftmiljö, uppdateringsrutiner och säkerhetskopiering.

Flexibilitet handlar om hur systemet anpassas utan kodändringar och hur konfigurationen förvaltas över tid. Specificera support och incidenthantering som svarstider och åtgärdstider per allvarlighetsgrad, supportkanaler och tider, eskalationsvägar samt hur incidenter följs upp och rapporteras tillbaka.

Krav på informationssäkerhet, personuppgifter och incidentberedskap

Det finns ingen enskild lag om informationssäkerhet i Sverige. Kraven följer av parallella regelverk: cybersäkerhetslagen, dataskyddsförordningen GDPR och säkerhetsskyddslagen samt sektorsspecifik lagstiftning som DORA och patientdatalagen. Enligt en genomgång från Draftit beror vilket som gäller på sektor, vilken information ni hanterar och hur stora ni är. Upphandlingsmyndigheten beskriver informationssäkerhet som åtgärder för att skydda information – bland annat förhindra att den läcker ut, förvanskas eller förstörs – och att olika regelverk aktualiseras beroende på vilken typ av information som ska skyddas.

Cybersäkerhetslagen (2025:1506) trädde i kraft den 15 januari 2026, ersätter lagen (2018:1174) om informationssäkerhet för samhällsviktiga och digitala tjänster och genomför NIS2-direktivet (EU 2022/2555) i svensk rätt. Enligt Draftit omfattar lagen verksamhetsutövare i 18 sektorer. Sanktionsavgifterna kan uppgå till 10 miljoner euro eller 2 procent av global omsättning enligt cybersäkerhetslagen, och 20 miljoner euro eller 4 procent enligt GDPR. GDPR artikel 32 ställer krav på informationssäkerhet vid all behandling av personuppgifter.

I kravspecifikationen blir detta krav på åtkomststyrning per roll, loggning av åtkomst och ändringar, kryptering under överföring och i lagring samt rutiner för radering, gallring och utlämning av data vid avtalets slut. Incidentberedskap hör hit: både cybersäkerhetslagen och GDPR kräver snabb incidentrapportering, vilket enligt Draftit talar för att samla det operativa arbetet i ett incidenthanteringssystem. Systemet behöver därför stödja identifiering, loggning, klassning och rapportering av säkerhetsincidenter, och kraven bör ange vem hos er och hos leverantören som kontaktas och inom vilken tid.

Leverantörskedjan ingår också. Upphandlingsmyndigheten konstaterar att de flesta upphandlande organisationer, och därigenom deras leverantörer, med anledning av cybersäkerhetslagen kommer att behöva vidta ytterligare informationssäkerhetsåtgärder. Ställ därför krav på leverantörens egen informationssäkerhet, på underleverantörer och på hur incidenter kommuniceras. Håll kravspecifikationen på kravnivå och lägg detaljerna i ert ledningssystem för informationssäkerhet, så att dokumentet går att verifiera i stället för att bli en juridisk avhandling.

Regelverk för informationssäkerhet i Sverige

Kravkvalitet: så att varje krav går att förstå, prioritera och verifiera

Ett etablerat ramverk är ISO/IEC/IEEE 29148:2011, Systems and software engineering – Life cycle processes – Requirements engineering. Svensk kravterminologi förtecknar begrepp som refererar till eller är översatta från standarden: unik identifierare, syfte, ägare, kravtyp, härledda krav, svårighetsgrad, kravattribut och kravegenskap samt kvalitetsorden fullständigt, nödvändigt, konsistent, atomärt och komplett. Där finns också distinktionen mellan kravvalidering och kravverifiering och mellan intressentkrav, funktionella krav och processkrav.

I praktiken bör varje kravpost innehålla en unik identifierare som är beständig över versioner, en kravtext som beskriver en enda företeelse (atomärt), en kravtyp, en namngiven kravägare, kravets syfte och härledning till ett mål eller en process, svårighetsgrad samt prioritet och verifieringsmetod. Kravet ska vara nödvändigt – utan det uppfylls inte syftet – och kraven sinsemellan konsistenta, så att två poster inte motsäger varandra.

Skilj på kravvalidering och kravverifiering. Valideringen prövar om kraven beskriver rätt behov och görs tillsammans med dem som ska arbeta i systemet; verifieringen prövar om kraven är uppfyllda i lösningen, genom test, granskning av dokumentation, demonstration eller mätning. Ett krav som inte går att verifiera med någon av metoderna behöver skrivas om innan det går vidare till upphandling.

Prioritering, avgränsning och acceptanskriterier

Dela in kraven i ska-, bör- och kan-krav. Ska-kraven måste vara uppfyllda för att lösningen ska accepteras, bör-kraven är önskvärda och vägs in i utvärderingen, och kan-kraven är optioner som kan prissättas separat. Indelningen gör kravlistan användbar i utvärderingen: utan den går det inte att skilja avgörande från marginella krav när leverantörernas svar jämförs.

Koppla varje krav till hur det ska accepteras. Ange verifieringsmetod och, där möjligt, ett acceptanskriterium med mätbart värde: vilken transaktion som ska testas, vilket resultat som ska uppnås eller vilket dokument som ska granskas. Kravverifiering är ett eget begrepp i kravterminologin, och kravet och dess verifiering bör hanteras som en enhet redan i specifikationen.

Skriv också ut vad som ligger utanför. Markera vilka processer, system, integrationer och anpassningar som inte ingår, och vilka förutsättningar köparen ansvarar för under införandet. Avgränsningen gör att en senare diskussion om tillägg kan föras mot en känd utgångspunkt i stället för mot antaganden.

Ska-, bör- och kan-krav i affärssystemskravspecifikation

Förankring, granskning och förvaltning av kravbilden

Utse en kravägare per processområde – ekonomi, order, inköp, lager, projekt – och låt respektive ägare ansvara för sina krav genom hela arbetet. Samla först intressentkraven på verksamhetsnivå och bryt sedan ner dem i funktionella och icke-funktionella krav, i linje med begreppsapparaten i ISO/IEC/IEEE 29148. Kravbilden blir då spårbar bakåt till behovet som motiverade den.

Valideringen görs som en strukturerad genomgång med dem som utför arbetet, dem som ansvarar för data och informationssäkerhet och dem som äger integrationerna mot omgivande system. Gå igenom krav för krav och fråga om kravet beskriver rätt behov innan det är formulerat rätt – det är betydligt billigare att korrigera kravbilden än en färdig implementation.

Hantera ändringar med versionering. Låt identifierare bestå genom versioner, dokumentera beslut och motivering till varje ändring och håll en lista över krav som tillkommit men ännu inte prioriterats. Enligt SIS underlättar standarder och gemensamma begrepp vid upphandling och när avtal ska skrivas. Kravbilden bör därför vara fryst och beslutad innan förfrågningsunderlaget går ut; ändringar därefter hör hemma i en uttalad ändringshanteringsprocess.

Checklista: det här bör en kravspecifikation för affärssystem innehålla

Syfte och avgränsning: processer i affärssystemet, system kvar vid sidan om, nödvändiga integrationer och vad som uttryckligen inte ingår.

Nuläge: kartlagda flöden för ekonomi, order, inköp, lager och projekt, manuella steg och dubbelregistreringar samt mål för förbättringen.

Funktionella krav per process: ekonomi och redovisning, fakturering, inköp, orderhantering, lager och logistik, rapportering och analys, projekthantering samt dataflöden och gränssnitt mellan system.

Icke-funktionella krav: användbarhet, prestanda, tillgänglighet, skalbarhet, drift och underhåll, support, incidenthantering och flexibilitet – med mätbara värden där möjligt.

Informationssäkerhet: åtkomststyrning, loggning, skydd av personuppgifter, incidentberedskap och rapportering, krav på leverantörskedjan samt hänvisning till ert ledningssystem för informationssäkerhet.

Kravkvalitet: unik identifierare, kravtext, kravtyp, kravägare, syfte och härledning, svårighetsgrad, prioritet samt verifierings- eller acceptanskriterium för varje krav.

Förankring och förvaltning: namngivna kravägare, validering med verksamheten, versionering och ändringshantering samt beslutad kravbild innan upphandlingen startar.