Behovsanalys för programvara: krav och processer

Varför behovsanalys är avgörande för programvara

Upphandlingsmyndigheten beskriver behovsanalysen som steget där ni undersöker och preciserar behoven bakom upphandlingen. Analysen blir utgångspunkt för krav, villkor och kriterier i upphandlingsdokumenten, visar vilka förutsättningar som finns och ger underlag för dialog med potentiella leverantörer.

Myndigheten lyfter också att behovsanalysen stödjer både upphandlingsfasen och avtalstiden. För ett programvaruinköp har den tre funktioner: den styr krav och kriterier, ger underlag för leverantörsdialogen om lösningar och förutsättningar, och fungerar som referens när avtalet ska förvaltas, vidareutvecklas eller avslutas.

Arbetet ska ge en gemensam bild av förutsättningarna. Saknas den formuleras kraven ofta utifrån dagens system eller en enskild leverantörs produktbeskrivning, vilket gör det svårt att senare bedöma om ett anbud faktiskt löser verksamhetens behov.

Kartlägg behoven i hela organisationen

Första steget är att kartlägga behoven som inköpet ska tillgodose. Upphandlingsmyndigheten föreslår att ni går igenom: finns lärdomar från föregående inköpsprocess, hur ser hela organisationens behov ut, varför behövs inköpet nu, hur ska det tas om hand och användas, vad har fungerat bra respektive mindre bra i nuvarande avtal, vilka nya utmaningar påverkar framtida behov, och vilka krav som kan bli aktuella utifrån mål och behov.

Kartläggningen ska också svara på när behoven måste vara tillgodosedda och vad utebliven leverans kan få för konsekvenser. Det ger en tidsram för införandet och underlag för att bedöma vilka verksamhetskritiska processer som är beroende av programvaran.

Frågan om hela organisationens behov är särskilt viktig vid programvaruinköp. En lösning som bara utgår från den initierande enheten leder ofta till parallella system, egna sidolösningar och senare krav på utökade licenser. Kartlägg därför vilka enheter, roller och externa parter som ska arbeta i eller mot programvaran innan kravbilden låses.

Analysera nuläge och gap

En nulägeskartläggning beskriver hur behoven hittills har lösts. Enligt Upphandlingsmyndigheten innehåller den vanligtvis behovsområdets innehåll, befintliga kostnader, inköpsvolymer, organisationen kring behoven, integrationer mot andra system och tjänster, antal användare kopplade till behoven, särskilda kännetecken i behovsområdet samt angränsande uppgifter eller behovsområden.

Integrationspunkter och användarantal styr oftast både kostnadsbild och teknisk lösning vid programvaruinköp. Angränsande behovsområden visar om inköpet bör samordnas med andra avtal eller om gränssnitt måste regleras i avtalet.

Kartläggningen kan delvis göras med en gapanalys, som visar skillnaden mellan nuläge och önskat resultat efter upphandlingen. Gapet blir den samlade behovsbild som kraven ska utgå från.

Metoder för att fånga behov

Behoven kan kartläggas på flera sätt. Upphandlingsmyndigheten nämner interna dialoger och intervjuer med berörda verksamhetsansvariga, sakkunniga, användare, brukare, avtalscontrollers med flera, enkäter, fokusgrupper eller workshoppar, gapanalyser mellan nuläge och önskat läge, statistik om hur befintliga avtal används samt genomgång av och lärdomar från tidigare avtal.

Metoden bör följa programvarans komplexitet och organisationens storlek. Intervjuer med verksamhetsansvariga och sakkunniga ger detaljkunskap om arbetsflöden och undantag. Enkäter når snabbt många användare och visar var behoven finns. Workshoppar är effektiva när olika enheter ska enas om en gemensam behovsbild.

Statistik över befintliga avtal ger underlag som intervjuer sällan fångar: vilka funktioner som faktiskt används, var användningen är koncentrerad och var avtalet används mindre än planerat. Avtalscontrollers kan bidra med den bilden och med erfarenheter från uppföljning av nuvarande leverantör.

Från behov till krav och kriterier

Behovsanalysen är utgångspunkt för krav, villkor och kriterier i upphandlingsdokumenten. Ett behov formulerat som teknisk lösning låser kravbilden vid ett specifikt system. Ett behov formulerat som funktion eller resultat kan uppfyllas på flera sätt och utvärderas mot flera anbud.

Vid programvaruinköp delas kraven vanligen i funktionella krav, som beskriver vad programvaran ska kunna göra, och icke-funktionella krav, som beskriver egenskaper som prestanda, tillgänglighet, säkerhet och datahantering. I Upphandlingsmyndighetens nulägeskartläggning ingår vanligtvis integrationer mot andra system och tjänster samt antal användare kopplade till behoven.

Kraven behöver vara mätbara och prioriterade, och organisationens förutsättningar att följa upp dem måste prövas redan i analysen. Upphandlingsmyndigheten lyfter uttryckligen frågan om vilka förutsättningar organisationen har att följa upp de krav man vill ställa utifrån behoven. Ett krav som inte kan följas upp blir svårt att kräva åtgärd mot under avtalstiden.

Dokumentera och skapa spårbarhet

Upphandlingsmyndigheten rekommenderar noggrann dokumentation av behovsanalysen. Skälet är att allt bör vara dokumenterat om oklarheter uppstår i upphandlingen senare.

Spårbarhet från behov till krav skapas genom att varje krav och kriterium kopplas till behovet det avser. Då går det att i efterhand förklara varför ett krav ställs och att prioritera mellan krav om förutsättningarna ändras.

Spårbarheten stödjer också uppföljningen: när varje krav kan härledas till ett dokumenterat behov går det att bedöma om en levererad funktion löser det ursprungliga problemet, och att hantera ändringar utan att tappa bort vilka behov som låg bakom.

Välj process för programvaruprojektet

Vattenfallsmetoden är sekventiell och delar arbetet i statiska faser – kravspecifikation, analys, design, testning, realisering och underhåll – som genomförs i tur och ordning. Den ger bra styrning i varje fas och ett mer formellt planeringsstadium. Enligt beskrivningen ökar det sannolikheten att fånga alla projektkrav direkt och minskar risken att tappa information i inledande faser, men den ger inte mycket svängrum om inriktningen ändras under projektet.

Agil projektledning arbetar i korta leveranscykler, sprintar, och används ofta i systemutveckling eftersom problem kan upptäckas och rättas tidigt i stället för att vänta till teststadiet. Den passar projekt som kräver flexibilitet och snabbhet, med realtidskommunikation i självgående team, och ger repeterbara processer, omedelbar återkoppling, korta ledtider och minskad komplexitet. Hybrida arbetssätt kombinerar inslag från båda.

Scrum är den strukturerade agila varianten: arbetet sker i fasta arbetsintervall, sprintar, där en till fyra veckor är en vanlig längd. Varje sprint har ett mål, startar med ett planeringsmöte där teamet skapar en uppgiftslista, fortsätter med dagliga framstegsmöten och avslutas med en genomgång av arbetet och ett retrospektiv.

Kanban arbetar i stället i ett kontinuerligt flöde utan tidsavgränsade perioder. Hela arbetsprocessen visualiseras på en tavla med kolumner, så teamet snabbt ser om uppgifter hopar sig i någon fas och kan identifiera flaskhalsar. Valet mellan metoderna påverkas av bransch, projekttyp, teamets storlek och hur många eller få justeringar som väntas under projektet – det vill säga hur stabil behovsbilden är.

Roller och ansvar i behovsarbetet

Projektledarens huvudsakliga syfte är att säkerställa ett framgångsrikt projekt. Framgång definieras här som att projektet uppnår både projekt- och effektmål inom budget och tidsambitioner. Projektledaren ansvarar både för projektleveransen och för att de önskade resultaten eller effekterna realiseras.

Scrum Masterns primära syfte är i stället att det agila teamet fungerar så effektivt som möjligt, med fokus på teamets förmåga att kontinuerligt skapa mesta möjliga värde och att ständigt utvecklas och förbättras. Rollen stödjer produktägaren, hjälper teamet att identifiera och undanröja hinder och för teamets talan gentemot övriga verksamheten. Titeln varierar mellan organisationer och kan även vara agil coach, Kanban lead eller Kanban Master.

Rollerna kompletterar varandra snarare än konkurrerar: projektledaren håller projekt- och effektmålen inom budget och tid, medan Scrum Mastern arbetar med teamets effektivitet och ständiga förbättring. I behovs- och kravarbetet tillkommer verksamhetsrepresentanterna, som äger behoven, prioriterar mellan dem och svarar på vad som är verksamhetskritiskt – en uppgift som varken projektledaren eller Scrum Mastern kan fylla på egen hand.

Programvaruspecifika hänsyn

Fyra faktorer återkommer i behovsanalysen för programvara. Integrationer mot andra system och tjänster avgör både teknisk lösning och kostnad, eftersom varje gränssnitt behöver beskrivas och förvaltas. Antal användare styr volym- och licensbehov och därmed kostnadsbilden. Dataflöden och datahantering avgör krav på struktur, tillgänglighet och livscykel för uppgifterna. Förvaltning över tid och leverantörsberoende avgör hur lösningen kan vidareutvecklas, driftas och avvecklas.

Leverantörsberoendet bör prövas redan i analysen: vem äger data och konfiguration, vilka möjligheter finns att byta leverantör eller driftsform, och hur påverkas verksamheten om avtalet upphör. Det påverkar vilka villkor och kriterier som behöver formuleras i upphandlingsdokumenten.

Öppen programvara är en aspekt att överväga när källkodens tillgänglighet, vidareutveckling och delning är viktig för behoven. Öppen programvara innebär att källkoden är tillgänglig för vem som helst att använda, läsa, vidareutveckla och dela vidare. I svensk offentlig sektor finns Offentligkod som exempel på delning och återanvändning: en sammanställning av öppen programvara som används av offentliga organisationer, med syftet att underlätta för andra.

Programvaruspecifika faktorer i behovsanalys