Foto till artikeln Vad bör ingå i en kravspecifikation för affärssystem?
Foto av nanoslavic på Pixabay

Verktygsguider

Vad bör ingå i en kravspecifikation för affärssystem?

En kravspecifikation har två uppgifter: att tvinga verksamheten att enas om vad som faktiskt ska lösas, och att ge leverantörer ett underlag som går att svara på och jämföra.

Detta är en redaktionell pseudonym för publikationen, inte ett påstående om en oberoende verifierad personlig identitet. Ursprunglig redaktionell byline: Redaktion Verktyg.

Syfte och utgångspunkt: varför en kravspecifikation för affärssystem?

En kravspecifikation har två uppgifter: att tvinga verksamheten att enas om vad som faktiskt ska lösas, och att ge leverantörer ett underlag som går att svara på och jämföra.

SIS beskriver standarders syfte som att skapa enhetliga och transparenta rutiner som parterna kan enas kring. Standarder underlättar upphandling och avtalsskrivning eftersom köpare och leverantörer talar samma språk. Samma logik gäller kravspecifikationen: den låser begrepp, avgränsningar och förväntningar innan avtal tecknas.

Utgångspunkten är en strukturerad förstudie. En förstudie med tydliga affärsmål lägger grunden för hela upphandlingen och minskar risken för kostsamma misstag. Rätt lösning kan effektivisera processer och ge bättre beslutsunderlag. Ett felaktigt val kan leda till höga kostnader och begränsad flexibilitet.

Kravspecifikationen är dokumentet där förstudiens slutsatser blir prövbara. Den dokumenterar funktionella och icke-funktionella krav. Den ska kunna användas av tre parter samtidigt: verksamheten som beställare, upphandlingsfunktionen som prövar anbud och leverantören som ska realisera kraven – utan att någon tolkar om innebörden.

Svensk kravterminologi samlar begreppsapparaten för krav och kravhantering, från kravhierarkier och kravtyper till kravattribut och kravroller.

För affärssystem ska kravspecifikationen namnge de standarder och regelverk som styr kravområdena. SS-EN ISO/IEC 27002:2022 ger informationssäkerhetsåtgärder. Dataskyddsförordningen (GDPR) gäller personuppgiftsbehandling.

En guide till innehållet bör namnge minst SS-EN ISO/IEC 27002:2022, Swedacs föreskrifter för certifieringsorgan för IT-säkerhet och GDPR. Ange exakta beteckningar och myndigheter så att anbudsprövningen blir transparent.

Kravområdena bör omfatta processer och funktioner, icke-funktionella krav, integration och data, driftform och moln, internationella krav, leverantör och implementation, verifiering och spårbarhet samt upphandling och utvärdering. Personuppgiftsbehandling enligt GDPR ska ingå i säkerhets- och datakraven.

Viktiga standarder och regelverk i svenska kravspecifikationer

  • SS-EN ISO/IEC 27002:2022Informationssäkerhet, cybersäkerhet och integritetsskydd – informationssäkerhetsåtgärder
  • Swedacs föreskrifterOm certifiering av IT-säkerhet; gäller ackrediterade organ enligt STAFS 2015:8 och STAFS 2013:5
  • GDPRDataskyddsförordningen (EU) – gäller i hela EU, inkl. Sverige, för automatiserad och vissa manuella behandlingar
  • Integritetsskyddsmyndigheten (IMY)Myndighet som övervakar GDPR-tillämpning i Sverige

Från behov och processer till krav

Arbetet börjar i verksamheten, inte i leverantörernas produktkataloger. Kartlägg affärsmål, processer och intressenter: flöden, roller, volymer, fel och manuella moment, samt beslut som i dag fattas på bristfälligt underlag. I svensk kravterminologi kopplas verbet tillgodose till behov. Krav formuleras för att tillgodose ett identifierat behov, inte för att beskriva en vald produkt.

Omvandlingen från behov till krav görs med dokumenterade metoder: intervjuer och workshops med processägare, nulägesanalys, genomgång av avvikelserapporter och manuella stöddokument, samt volymmätningar för de flöden som ska dimensionera lösningen.

Registrera varje kandidatkrav med sin källa: vilket behov, vilken process och vilken intressent som ligger bakom. Källan behövs senare vid prioritering och ändringar.

En vanlig fallgrop är att kraven skrivs som beskrivningar av en färdig lösning. Kravterminologin skiljer på lösningsoberoende krav och begränsningar. Begränsningarna bör redovisas separat. Bindande förutsättningar som befintlig systemmiljö, ingångna avtal eller tvingande regelverk ska framgå som just begränsningar – inte blandas in bland krav leverantören förväntas uppfylla på valfritt sätt.

Tvingande regelverk ska namnges. När personuppgifter behandlas bör kravspecifikationen ange dataskyddsförordningen (GDPR) och Integritetsskyddsmyndigheten (IMY).

GDPR gäller i princip all automatiserad behandling av personuppgifter och i vissa fall även manuell behandling. Reglerna ska tillämpas oberoende av vem som utför personuppgiftsbehandlingen.

Struktur, begrepp och prioritering av krav

En kravspecifikation blir hanterbar först när den har en struktur. Svensk kravterminologi omfattar kravhierarkier och krav på olika abstraktionsnivåer, kategorisering och klassificering av krav, kravtyper, kravattribut och kravmängdsattribut samt kravschabloner och kravmönster. Gemensam begreppsapparat är själva poängen – gemensamt språk ger bättre krav.

Kravattribut gör kraven spårbara och styrbara. Sätt attribut per krav: unikt id, benämning, källa till behovet, kravägare i verksamheten, prioritet, status och verifieringsmetod. Prioriteringen bör följa en fast skala som alla parter känner, till exempel ska-krav, bör-krav och kan-krav. Då kan leverantören bedöma vad som är bindande och vad som är önskvärt vid en given budget.

Kraven som helhet har också egenskaper: fullständighet, konsistens och avgränsning mot det som inte ingår. Funktionella och icke-funktionella krav beskrivs i kravterminologin som de problematiska kravtyperna. Bestäm i förväg vilken kategori ett krav hör till och vilken struktur det ska följa. Låt inte kategorin avgöra om kravet blir formulerat.

En kravspecifikation byggs av namngivna beståndsdelar, inte bara rubriker. Dit hör egenskaper för enskilda krav och egenskaper för kravmängder, kravtyper samt kategorisering och klassificering av krav. Dit hör också grundläggande kravbegrepp, intressenter och behov samt steget från behov till krav.

Dokumentet består dessutom av kravrelaterade arbetsprodukter: kravschabloner och kravmönster, kravnotationer, kravmodeller och kravroller. Assuranskrav och assuransfall förs till samma uppsättning. Utan dessa beståndsdelar är dokumentet ofullständigt, även om rubrikerna finns på plats.

En samlad innehållslista kan byggas kring Svensk kravterminologis avsnitt. Den omfattar grundläggande kravbegrepp, intressenter och behov, krav och kravmängder, från behov till krav, kravhantering och kravteknik, kravhierarkier, prioritering, spårbarhet och kravglidning, kravallokering, validering och verifiering.

Listan fortsätter med kravtyper, kategorisering, säkerhetskrav, assuranskrav, kravmodeller, kravnotationer, kravschabloner, kravattribut och kravroller. Den visar vilka beståndsdelar som ska finnas med, inte bara vilka rubriker dokumentet har.

Krav som rör GDPR är kravområden i sig. De bör ha kravägare, prioritet, status och verifieringsmetod som alla andra krav.

Kravspecifikationen bör namnge de standarder och regelverk som styr respektive kravområde: SS-EN ISO/IEC 27002:2022, Swedacs föreskrifter och GDPR.

Jämförelse av kravtyper i en kravspecifikation för affärssystem

  • Funktionella kravBeskriver vad systemet ska kunna göra – t.ex. hantera beställningar, fakturering eller lagerstyrning. Formuleras som aktiviteter och resultat utan att binda till gränssnitt.
  • GDPR-kravReglerar behandling av personuppgifter – inklusive rättslig grund, lagringstid, radering och ansvar för dataskydd. Gäller även om leverantören är biträde.

Prioritering av krav efter nivå (enligt svensk kravterminologi)

  1. Ska-kravBindande krav som måste uppfyllas för att systemet ska vara acceptabelt. Exempel: GDPR-kompatibilitet, säker åtkomst till kritiska data.
  2. Bör-kravÖnskvärda men inte obligatoriska krav. Kan prioriteras bort vid budgetbegränsningar. Exempel: mobilapp med avancerade funktioner.
  3. Kan-kravTillfälliga eller framtida funktioner som inte ingår i initial version. Exempel: AI-baserad prognos inom tre år.

Obligatoriska element i en kravspecifikation för affärssystem

  • Kravhierarki med abstraktionsnivåerFunktionella, icke-funktionella, säkerhets-, GDPR- och integrationskrav
  • Kravattribut per kravUnikt ID, källa, kravägare, prioritet (ska/bör/kann), status, verifieringsmetod
  • Verifikations- och valideringsrutinerGranskning, demonstration, test med egen data – med tydliga tidpunkter
  • Spårbarhet från behov till testfallKoppling mellan behov → krav → test → ändringslogg
  • Hänvisning till exakta standarderSS-EN ISO/IEC 27002:2022, Swedacs föreskrifter, GDPR, IMY

Funktionella krav: processer och funktioner

Ett affärssystem är en integrerad plattform. Den samlar och automatiserar centrala affärsprocesser. Ekonomi, inköp, produktion, lager, försäljning och kundhantering knyts ihop i ett gemensamt system med en delad databas. Kravspecifikationen bör spegla samma processområden och beskriva vad systemet ska göra i varje flöde.

För varje process behöver specifikationen besvara flera frågor. Vad utlöser processen? Vilka in- och utdata används? Vilka roller och behörigheter är inblandade?

Vilka beslut och atteststeg krävs? Hur hanteras avvikelser och undantag? Vilka gränssnitt finns mot angränsande flöden?

Typiska kravområden är order till kassa, inköp till betalning, prognos till produktion, lagerpåfyllnad samt retur- och reklamationshantering inom kundservice. Formulera kraven som aktiviteter och resultat – vad som ska kunna utföras och vilket utfall det ska ge – snarare än som skärmbilder eller menyval. Skärmnivåbeskrivningar binder lösningen i förtid och gör anbuden svårare att jämföra. Process- och resultatkrav går att verifiera oberoende av vilket gränssnitt leverantören erbjuder.

Kravspecifikationen bör därför namnge processområdena ekonomi, inköp, produktion, lager, försäljning och kundhantering. För varje område anges vilka aktiviteter som ska utföras och vilka resultat de ska ge.

Kundhantering innehåller ofta personuppgifter. Kravspecifikationen bör därför beskriva var personuppgifter samlas in, lagras, ändras, raderas och lämnas ut. Den bör namnge GDPR och dataskyddsombud där sådant finns.

Icke-funktionella krav: prestanda, användbarhet, gränssnitt och säkerhet

De icke-funktionella kraven kompletterar de funktionella och avgör om lösningen är användbar i praktiken. Fyra vanliga områden är prestanda, användbarhet, gränssnitt och säkerhet.

Varje sådant krav måste vara mätbart och verifierbart. I stället för ”snabb” och ”användarvänlig” anges ett mått, en betingelse och en verifieringsmetod. Exempel: svarstid vid ett angivet antal samtidiga användare och en angiven datamängd, tillgänglighet i procent av avtalad drifttid, maximal överföringstid för integrationer samt andel lyckade transaktioner. Ange hur måttet ska mätas och när. Användbarhetskrav bör kopplas till konkreta uppgifter som en viss roll ska kunna utföra inom en angiven tidsram.

Säkerhetskraven bör omfatta autentisering, behörigheter per roll och enhet, loggning av ändringar, kryptering och spårbarhet i affärskritiska transaktioner. Standarden SS-EN ISO/IEC 27002:2022 har titeln Informationssäkerhet, cybersäkerhet och integritetsskydd – Informationssäkerhetsåtgärder och är en av SIS mest sålda standarder. Den ger informationssäkerhetsåtgärder.

Om certifiering av IT-säkerhet ska krävas i upphandlingen måste specifikationen ange vem som får utfärda den. Swedacs föreskrifter tillämpas på certifieringsorgan som är eller ansöker om att bli ackrediterade för certifiering av IT-säkerhet hos IT-produkter, IT-system samt skyddsprofiler. Den tidigare föreskriften STAFS 2007:21 är upphävd genom STAFS 2019:3.

Swedacs föreskrifter är ett komplement till STAFS 2015:8 om ackreditering samt STAFS 2013:5 om ackreditering av organ som certifierar produkter. Om upphandlingen kräver certifiering av IT-säkerhet ska kravspecifikationen namnge Swedac och det regelverk som certifieringsorganet följer.

Dataskyddsförordningen (GDPR) är en EU-lagstiftning som trädde i kraft den 25 maj 2018. Den gäller i hela EU och syftar till en enhetlig och likvärdig nivå för skyddet av personuppgifter. Reglerna gäller i princip all automatiserad behandling av personuppgifter och i vissa fall även manuell behandling. Vid upphandling av IT-system blir de ofta aktuella.

Kravspecifikationen bör namnge Integritetsskyddsmyndigheten (IMY) och de grundläggande principerna i GDPR. Artikel 5 i GDPR anger sju principer. De omfattar laglighet, korrekthet och öppenhet, ändamålsbegränsning, uppgiftsminimering, riktighet, lagringsminimering, integritet och konfidentialitet samt ansvarsskyldighet.

Skyldigheterna sträcker sig från insamling och lagring till tillgång och radering av personuppgifter. Personuppgifter ska raderas när de inte längre behövs och skyddas mot obehörig åtkomst, förlust och förstöring. Det finns sex rättsliga grunder i dataskyddsförordningen; en ska vara uppfylld för varje behandling.

Kravspecifikationen bör kräva tekniska och organisatoriska åtgärder, privacy by design, utbildning av personal och dataskyddsombud där det är aktuellt. Brott mot GDPR kan leda till böter på upp till 4 % av den globala årsomsättningen eller 20 miljoner euro, vilket är högst. Organisationen ska kunna visa att den lever upp till dataskyddsförordningen.

Om leverantören behandlar personuppgifter för kundens räkning är den upphandlande organisationen normalt personuppgiftsansvarig och leverantören personuppgiftsbiträde. Kravspecifikationen bör reglera ansvar, ändamål och skyddsåtgärder för behandlingen.

Integrations-, data- och informationskrav

Integrationskraven avgör ofta om affärssystemet ersätter isolerade system som inte kommunicerar med varandra. Den integrerade plattformen har en delad databas. Den ger aktuell affärsdata från hela verksamheten. Det möjliggör snabbare och mer välgrundade beslut.

Lista varje system som ska integreras. Ange per integration: syfte, dataobjekt, riktning, frekvens, format, ansvar vid fel samt hur avvikelser larmas och hanteras.

Datakraven hör ihop med integrationerna. De bör svara på vilket dataobjekt som ägs och förvaltas var, vilka fält som är obligatoriska och vilka valideringar som ska ske vid källan. De bör också svara på hur dubbletter förhindras, hur historik och arkivering hanteras samt hur data kan lämnas ut vid avtalets slut.

Bestäm vilket system som är auktoritativt källsystem per dataobjekt. Bestäm också vad som ska hända när två system innehåller motstridiga uppgifter.

Krav på datakvalitet blir verkningslösa om ingen äger dem. Knyt därför varje datakrav till en roll i verksamheten med ansvar för innehåll, kvalitet och behörigheter. Kräv att leverantörens föreslagna lösning kan visa avvikelser mot uppsatta kvalitetsmått.

Dataarkitekturen ska visa var personuppgifter behandlas. Kravspecifikationen bör namnge GDPR och beskriva hur tillgång och radering hanteras. Den bör också kräva loggning av åtkomst och ändringar i affärskritiska transaktioner.

Kartlägg vilka personuppgifter som behandlas, varför och hur länge de behålls. Personuppgifter ska vara riktiga och inte behandlas fler än vad som behövs för ändamålen. Ange därför ändamål, rättslig grund, lagringstid och raderingsrutiner.

Driftform, moln, skalbarhet och tillgänglighet

Molnbaserade affärssystem ger svenska företag flexibilitet, skalbarhet och tillgång till realtidsdata oavsett var verksamheten bedrivs. Driftformen är därför ett kravområde, inte en teknisk detalj.

Specifikationen bör ange om molndrift förutsätts. Den bör också ange hur tillgänglighet mäts och följs upp, hur tjänsten skalas vid ökade volymer eller fler användare, hur ofta uppgraderingar sker och när underhållsfönster får ligga.

Komplettera med krav på supporttider och kanaler, åtkomst från mobil och distansarbetsplats samt prestanda vid hög belastning. Lägg också till rutiner för säkerhetskopiering och återställning samt villkor för datalagring och utlämning av data om avtalet upphör. Tillgänglighetskrav utan avtalad mätmetod och konsekvens vid avvikelse går inte att följa upp i efterhand.

Molnbaserade affärssystem behandlar ofta personuppgifter. Kravspecifikationen bör därför kräva att personuppgifter skyddas mot obehörig åtkomst, förlust och förstöring, och att data kan lämnas ut eller raderas när avtalet upphör.

GDPR gäller oavsett vem som utför personuppgiftsbehandlingen. Ange därför hur efterlevnaden följs upp i drift och vid uppgraderingar.

Internationella och koncernspecifika krav

Svenska företag med internationell verksamhet har särskilda behov kring flervaluta, koncernredovisning och lokala regelverk. Ett modernt affärssystem förutsätts hantera dessa krav.

Specifikationen bör omfatta redovisnings- och transaktionsvalutor samt kurshantering vid transaktionstillfälle och bokslut. Den bör också omfatta enhetshierarkier och behörigheter per enhet, elimineringar mellan enheter samt rapportpaket för konsolidering.

Beskriv hur gemensam kontoplan och gemensamma kodplaner förhåller sig till lokala variationer. Beskriv också hur lokala rapporteringskrav och fakturaformat hanteras, samt på vilket språk och med vilka enheter gränssnitt och rapporter ska vara tillgängliga. Utgå från den rapporteringsstruktur koncernen faktiskt använder, så att systemet kan producera underlaget utan manuella mellanled.

GDPR gäller i hela EU. Organisationer utanför EU omfattas om de erbjuder varor eller tjänster till personer i EU eller övervakar deras beteende på nätet.

Kravspecifikationen bör namnge GDPR och IMY när personuppgifter behandlas i flera länder. Ange också hur lokala rapporteringskrav och fakturaformat hanteras.

Krav på leverantör, implementeringspartner och stöd

Valet av implementeringspartner är lika viktigt som valet av system. Erfarenhet, branschkunskap och långsiktigt stöd avgör framgången. Kravspecifikationen bör därför ställa krav på partnern och inte bara på programvaran.

Den bör omfatta dokumenterad erfarenhet från liknande verksamhet och bransch, referensuppdrag som går att kontakta samt vilka nyckelresurser som avses arbeta i projektet. Den bör också omfatta hur kompetens säkerställs och hur support och vidareutveckling organiseras.

En lyckad implementation kräver förankring hos ledningen, engagerade projektteam och realistiska tidsplaner. Det omsätts i krav på projektmodell, milstolpar, acceptanskriterier per fas och bemanning från båda parter. Det gäller också utbildning och kunskapsöverföring till den egna organisationen. Lägg till villkor för supportavtal med svarstider och former för ändringsbegäran efter driftsättning.

Om leverantören behandlar personuppgifter för er räkning är den normalt personuppgiftsbiträde. Kravspecifikationen bör kräva att leverantören kan visa hur GDPR följs, hur dataintrång hanteras och hur biträdet vidtar lämpliga skyddsåtgärder.

Verifiering, validering och spårbarhet

Varje krav ska gå att följa upp. Ange därför redan i specifikationen vilken verifieringsmetod som gäller för respektive krav. Det kan vara granskning av dokumentation, demonstration i systemet, test med egna data eller analys. Ange också när verifieringen ska ske.

Kravterminologin behandlar validering och verifiering av krav respektive system. Begreppen håller isär två frågor: att rätt krav har ställts (validering) och att systemet uppfyller dem (verifiering).

Spårbarhet innebär att varje krav kan följas från behov via krav till testfall och acceptans, och vidare till ändringsloggen. Kravterminologin omfattar både spårbarhet och kravglidning samt kravallokering, det vill säga hur krav fördelas mellan systemets delar. Utan spårbarhet går det inte att vid leverans visa vad som är uppfyllt, delvis uppfyllt eller inte uppfyllt.

Kravglidning – att kraven ändras successivt under projektet – påverkar både tid och kostnad. Möt den med en formell ändringsrutin. Nya och ändrade krav registreras, värderas mot prioritet, versionshanteras och prissätts innan de arbetas in. Då blir kopplingen mellan ändrat innehåll och ändrade förutsättningar dokumenterad.

GDPR-krav bör verifieras som andra krav. Ange verifieringsmetod, ansvarig roll och tidpunkt för granskning av dokumentation, tekniska åtgärder och raderingsrutiner.

Kravspecifikationen som underlag för upphandling och utvärdering

Kravspecifikationen för ett affärssystem bör innehålla tydliga administrativa förutsättningar, krav på anbudets form och innehåll samt utvärderingskriterier som är kända i förväg.

Kräv att anbudsgivaren svarar krav för krav i ett fast svarsformat – uppfyllt, delvis uppfyllt eller ej uppfyllt. Svaret ska innehålla motivering och hänvisning till hur kravet löses. Kräv också en prisbilaga där kostnaderna redovisas var för sig: licens eller prenumeration, implementation, drift och support, utbildning och vidareutveckling. Då blir anbuden jämförbara och prövningen transparent.

Standarder säkerställer kompatibilitet och ger trovärdighet både lokalt och globalt. Genom att hänvisa till etablerade standarder inom de områden där de finns – till exempel informationssäkerhet – får kravspecifikationen en referensram som båda parter känner igen. Det minskar utrymmet för egna tolkningar i anbudsprövningen.

Vid hänvisning till standarder bör kravspecifikationen ange exakta beteckningar. Standarden för informationssäkerhet, cybersäkerhet och integritetsskydd i avsnittet ovan är ett sådant namn.

Vid upphandling som innebär att leverantören behandlar personuppgifter för organisationens räkning ska GDPR följas. Upphandlingsmyndigheten beskriver att upphandlande organisationer ofta är personuppgiftsansvariga och att leverantören ofta är personuppgiftsbiträde.

Kravspecifikationen bör därför namnge Integritetsskyddsmyndigheten (IMY) och reglera ändamål, behandling och skyddsåtgärder enligt dataskyddsförordningen.

Vid hänvisning till standarder bör exakta beteckningar anges: SS-EN ISO/IEC 27002:2022 och Swedacs föreskrifter med STAFS-beteckningar.

Mer från Verktygsguider