Så skriver du en kravspecifikation för ett system, så att offerterna går att jämföra

Du skickar samma idé till tre leverantörer i ett mejl på två stycken. Tillbaka får du 25 000 €, 70 000 € och 140 000 €. Ingen har fel. Var och en har prissatt ett annat system: det som de föreställde sig när de läste ditt mejl.

En kravspecifikation löser det. Det är ingen byråkrati. Det är det billigaste sättet att se till att alla offererar samma sak, och att du får det system du hade i tankarna.

Siffrorna bekräftar det. I en studie från Project Management Institute var bristande kravhantering huvudorsaken i nästan hälften av fallen (47 %) när projekt inte nådde sina mål, och 5,1 % av varje dollar som lades på projekt gick förlorad på grund av det.

Vad en kravspecifikation är, och vad den inte är

Den beskriver vad systemet ska göra och varför. Inte hur. Hur är leverantörens uppgift, och att ge dem utrymme att föreslå en lösning är en av sakerna du betalar dem för.

I tyskspråkiga länder har skillnaden till och med namn: beställaren skriver ett Lastenheft (vad och varför), och leverantören svarar med ett Pflichtenheft (hur och med vad), enligt standarden DIN 69901-5. Internationellt beskriver ISO/IEC/IEEE 29148 kravhantering i detalj.

För ett medelstort företag behöver du inte hundra sidor. Fem till femton sidor som besvarar rätt frågor räcker.

Vad som ska stå i den

Avsnitt	Vilken fråga det besvarar	Exempel
Mål	Varför systemet, och hur du mäter framgång	”Tre personer skriver av beställningar från mejl två timmar om dagen. Mål: under 30 minuter.”
Nuläge	Hur det fungerar i dag, med vilka verktyg	”Beställningar kommer via mejl och Excel och skrivs in i affärssystemet för hand.”
Användare och roller	Vem som använder det och vad de får göra	”Säljare skapar beställningar, lagret bekräftar dem, administratörer ser allt.”
Processer	De viktigaste flödena, steg för steg	”Beställning kommer in, lagret kontrolleras, beställningen bekräftas, faktura skickas.”
Data	Vilka data, varifrån, hur mycket	”Cirka 300 beställningar om dagen och 5 000 kunder, importerade från affärssystemet.”
Integrationer	Vilka system det ska prata med	”Affärssystemet via dess REST-API, e-post, ekonomisystemet.”
Icke-funktionella krav	Hastighet, säkerhet, tillgänglighet, dataskydd, enheter	”Inloggning med Microsoft 365, data lagras inom EU, fungerar på en surfplatta i lagret.”
Acceptanskriterier	Hur du kontrollerar att det är klart	”En beställning från ett mejl finns i affärssystemet inom fem minuter utan manuell inmatning.”
Leveransomfattning	Vad som ingår utöver koden	”Utbildning, dokumentation, överlämning, de tre första månadernas support.”
Prioriteringar	Vad som måste finnas i första versionen	Måste, bör, kan

Skriv krav som går att kontrollera

Den vanligaste svagheten är ett krav som ingen kan kontrollera. ”Snabbt” betyder en sak för dig, en annan för leverantören och en tredje för en användare med långsam uppkoppling. Varje krav ska gå att testa vid leveransen:

Vagt	Kontrollerbart
Systemet ska vara snabbt	Beställningslistan laddas på under två sekunder med 10 000 beställningar
Användarvänligt	En ny lagermedarbetare bekräftar en beställning utan utbildning, på under en minut
Säkert	Inloggning med Microsoft 365 och tvåfaktorsautentisering; varje ändring av en beställning loggas med användare och tid
Integration med affärssystemet	Nya beställningar finns i affärssystemet inom fem minuter; om det inte svarar görs nya försök och en administratör får en avisering

Vad du ska utelämna

• Skärmdesign ner på pixeln, om det inte verkligen spelar roll. Beskriv vad användaren ska göra, inte var knappen sitter.
• Teknikval utan skäl. Om det finns ett skäl, skriv ner det: ”måste köras på vår SQL Server”, ”vårt team förvaltar .NET”. Låt annars leverantörerna föreslå.
• Varje undantag i första utkastet. Markera öppna frågor i stället. En bra leverantör frågar om dem, och svaren gör dokumentet bättre.

Måste, bör, kan

Ge varje krav en prioritet. Måste: utan det är systemet oanvändbart. Bör: viktigt, men det finns en väg runt. Kan: trevligt att ha.

Det ger två saker. Offerterna blir jämförbara, eftersom alla prissätter samma första version. Och du får en naturlig första release: bara måste-kraven, snabbt i drift, och resten följer när användarna har sett den.

Hur detaljerat dokumentet behöver vara beror också på avtalet. Med fast pris blir det en del av avtalet och kräver betydligt mer detaljer. Mer om det i vår artikel om fast pris eller löpande räkning.

Låt AI skriva första utkastet

Att skriva dokumentet är ofta det som får ett projekt att stå still i månader. AI kortar det rejält. Spela in ett samtal med dem som gör jobbet i dag, eller beskriv processen med egna ord, och ge det till en AI-assistent tillsammans med tabellen ovan. Be om ett utkast och en lista med öppna frågor.

Du läser och rättar fortfarande varje rad, för bara du känner verksamheten. Men att rätta ett utkast tar timmar, att börja från ett tomt papper tar veckor. En regel: klistra inte in konfidentiella uppgifter i ett publikt chattverktyg. Använd den version som ditt företag har godkänt, med era inställningar för dataskydd.

Vad som händer sedan

Skicka samma dokument till tre leverantörer och be var och en att svara krav för krav: hur de skulle lösa det, vad det kostar och vad som är oklart. I tyskspråkiga länder är det svaret ett Pflichtenheft.

Jämför sedan svaren, inte bara totalbeloppen. En leverantör som ställer bra frågor har läst dokumentet. En som inte frågar något har prissatt en gissning. Realistiska prisintervall hittar du i vår artikel om vad skräddarsydd mjukvara kostar.

Så arbetar vi

Precis här börjar vi ofta. ProCoding är en .NET-studio från Split i Kroatien: vi bygger affärsapplikationer i .NET och Blazor och för in AI i affärsprocesser. I en kort analys går vi igenom dina processer med de personer som kan dem, skriver kravspecifikationen tillsammans med dig och ger en uppskattning i intervall. Dokumentet är ditt, och du kan be andra leverantörer offerera på det också. Första steget: Boka ett kostnadsfritt samtal på 30 minuter.

Källor

• Requirements Management: A Core Competency for Project and Program Success, PMI’s Pulse of the Profession, Project Management Institute, augusti 2014
• Lastenheft, Wikipedia (definitioner enligt DIN 69901-5)
• ISO/IEC/IEEE 29148:2018, Requirements engineering, ISO