Grunderna i kravhantering: din steg-för-steg-guide

Det är fredagskväll och du ska beställa pizza. Du har telefonen i ena handen och en lista med önskemål från dina vänner i den andra. Men först måste du gå igenom allas önskemål och bestämma vilken typ av pizza du ska beställa. Pepperoni? Ost? Vegetarisk?

Att beställa pizza börjar kännas kusligt likt att hantera krav för din senaste produktlansering. Precis som i situationen ovan handlar kravhantering om att lyssna på intressenterna och förstå hur man bäst kan tillgodose deras behov. 

Vad är kravhantering?

Kravhantering är ett sätt att säkerställa att dina slutliga projektleveranser uppfyller kundernas och interna intressenters behov. I det här fallet är ett krav något som intressenter behöver eller vill ha från din produkt. Intressenter kan vara interna (som tvärfunktionella partner) eller externa (som kunder). 

Kravhantering används oftast av utvecklingsteam som arbetar med programvaruprodukter och funktioner, men kan också tillämpas mer generellt på projekthantering. Ett krav kan till exempel vara en funktion som gör det möjligt för kunder att använda din produkt, eller en aspekt av din produkt som hjälper tvärfunktionella partner att uppnå sina mål. 

Innan du börjar arbeta med en produkt måste du komma överens om de exakta kraven så att du kan se till att du ger intressenterna vad de behöver. Kravhantering hjälper dig att dokumentera och prioritera krav, hålla reda på ändringar och hålla dig i linje med intressenter under hela projektets livscykel. Det hjälper dig också att hantera förändrade krav och se till att projektet håller sig inom omfattningen. 

Vad är ett krav? 

Ett krav är en komponent som behöver implementeras för att en funktion eller produkt ska bli slutförd. Med andra ord är det något som din produkt måste ha eller göra för att uppfylla dina intressenters behov. Programvaruprodukter kan ha hundratals krav. Men oavsett hur många krav din produkt har bör alla vara: 

• Nödvändiga: Du behöver kravet för att uppnå dina Business- eller produktmål. 

• Specifika: kravet är detaljerat och har ett tydligt syfte. 

• Förståeliga: kravet är tydligt skrivet och lätt att förstå. 

• Korrekta: kravet har tillräckligt med korrekt information om utmaningen eller behovet som kravet tar upp. Det innebär att du i stället för att bara beskriva vad som behöver göras också bör klargöra varför kravet är viktigt. 

• Genomförbart: Du bör undersöka kravet för att se till att du kan implementera det med din nuvarande teknikstack och kodinfrastruktur.

• Testbar: Du bör kunna testa kravet genom användartestning, A/B-testning eller någon annan metod. 

Här är ett exempel. Föreställ dig att du skapar en app och att ett av kraven är att hela appen måste översättas till engelska, kinesiska, japanska och franska eftersom de språken stämmer överens med dina viktigaste Business-marknader.

• Det här kravet är nödvändigt för att lansera appen på företagets huvudmarknader och uppnå affärsmålen. 

• Det är specifikt eftersom du beskriver vilka språk du behöver och att hela appen behöver översättas. 

• Det är begripligt eftersom det inte går in på tekniska detaljer, utan är skrivet på ett sätt som dina teammedlemmar och tvärfunktionella intressenter kan förstå. 

• Det är korrekt eftersom du tydligt har beskrivit varför kravet är viktigt – eftersom engelska, kinesiska, japanska och franska är i linje med företagets primära marknader. 

• Det är genomförbart eftersom du redan har byggt prototyper och testfall på andra språk, så du vet att lokalisering är möjlig och kommer att fungera som förväntat. 

• Det är testbart eftersom du har ett system för att testa och bekräfta att varje översatt version är korrekt. 

Varför är kravhantering viktigt? 

För att skapa en bra produkt behöver du kravhantering. Här är anledningen: 

• Leverera rätt funktioner. Kravhanteringsprocessen hjälper till att definiera vad dina användare behöver genom att förstå hur de interagerar med produkten. Det hjälper dig att anpassa dina leveranser till dina kunders grundläggande behov. 

• Anpassa till företagets mål. När du dokumenterar och prioriterar krav bör du se till att de överensstämmer med de övergripande Business-målen. Till exempel skulle ett krav på att översätta din app till 12 språk stödja ett businessmål om att expandera till internationella marknader. Om ett krav inte stöder affärsmålen betyder det förmodligen att du bör investera resurser någon annanstans – eller ha en riktigt bra anledning till varför kravet är viktigt. 

• Förhindra omfattningskrypning. Definierade krav fungerar som en projektomfattning – de sätter gränser och definierar exakt vilka mål och leveranser du ska uppnå. Att definiera kraven i förväg hjälper dig att identifiera potentiella hinder och att säga nej när intressenter försöker lägga till ytterligare krav.

• Undvik hinder. Att skapa en produkt är komplext – det finns programvaruutveckling, design och testning – för att inte tala om komplexa kodstackar och tekniksystem. Kravhantering hjälper dig att planera hur du utvecklar en produkt inom kodstackens begränsningar och hålla reda på vad du behöver åstadkomma i varje steg av produktutvecklingsprocessen.

Vem är ansvarig för kravhantering? 

Vem som ansvarar för kravhanteringen beror på ditt individuella projekt eller team. Med det sagt är det vanligtvis produktägare eller produktchefer som hanterar kraven för utvecklingsteam. De två rollerna liknar varandra, förutom att produktägare är en standardroll i Scrum-team medan produktchefer är en mer universell roll, oavsett om teamet använder en agil metod eller inte. Om du arbetar med ett mer allmänt projekt i stället för att utveckla en produkt är projektledaren ansvarig för kravhanteringen. 

Kravhantering kräver tvärfunktionellt samarbete mellan teamet och projektets intressenter. Du behöver samla in feedback från intressenter, arbeta med dem för att förstå varje krav och hjälpa ditt team att planera hur de ska hantera varje behov. Det innebär att personen som hanterar kraven för ditt projekt bör ha goda samarbetsförmågor och vara bra på tvärfunktionell kommunikation, eftersom personen kommer att vara i centrum av allt.

Vilka är de olika typerna av krav? 

Det finns tre huvudtyper av krav: business-krav, användarkrav och systemkrav. Det är viktigt att definiera de olika typerna av krav innan arbetet startar, eftersom det ofta avgör vilka intressenter du behöver samarbeta med. 

Här är en översikt över de olika typerna av krav: 

Business-krav

Business-krav är de övergripande företagsmålen eller mätvärdena som din produkt tjänar. De är inte nödvändigtvis något som produkten behöver göra, utan snarare saker som ditt företag behöver göra för att tillfredsställa både interna och externa intressenter. 

Tänk dig till exempel att du arbetar för ett onlineföretag och att ditt försäljningsteam använder ett innehållshanteringssystem för att skapa och uppdatera produktsidor på din webbplats. För att hantera det växande lagret förbättrar produktteamet sökfunktionen i innehållshanteringssystemet.

Produktteamets projekt uppfyller följande Business-krav: Skala produktinventariet med 50 % under första kvartalet. För att samla krav som dessa i ett enda, organiserat format kan du använda en mall för dokument för business-krav.

Användarkrav

Användarkrav definierar vad användarna behöver från din produkt och hur de kommer att interagera med den. De beskriver en smärtpunkt eller en åtgärd som kunden vill utföra, plus hur produkten ska lindra den smärtpunkten eller hjälpa kunden att utföra den önskade åtgärden.  

Agila team formaterar vanligtvis användarkrav som användarberättelser, som är informella förklaringar av en programvarufunktion skrivna ur slutanvändarens perspektiv. Användarberättelser följer det här formatet: ”Som en [persona] vill jag [programvarumål], så att [resultat].” 

Låt oss återgå till CMS-exemplet som vi beskrev ovan. Här är ett exempel på en användarberättelse skriven ur slutanvändarens perspektiv – i det här fallet en säljare som använder innehållshanteringssystemet för att utföra sina arbetsuppgifter. 

“Som säljare vill jag enkelt kunna söka efter och hitta specifika produktannonser i vårt innehållshanteringssystem så att jag kan uppdatera och hantera vårt växande onlineinventarie.” 

Systemkrav

Systemkrav definierar vad produkten kommer att göra. Tänk på det så här: medan användarkraven beskriver produktfunktionernas ”varför” och ”vad” ur användarens perspektiv, definierar systemkraven ”hur” funktionen ska byggas ur utvecklingsteamets perspektiv. 

Systemkrav delas ofta upp i funktionella krav och icke-funktionella krav. Funktionella krav definierar vad produkten ska göra, medan icke-funktionella krav definierar hur bra produkten utför sina funktioner. Det innebär att icke-funktionella krav vanligtvis har att göra med säkerhet, prestanda och tillförlitlighet. 

Här är ett exempel på hur ett teknikteam kan dela upp ovanstående CMS-användarkrav i systemkrav: 

Funktionella krav

• Varje produktannons lagrar följande information: produkttyp, skapandedatum, författare, webbadress och publiceringsstatus.

• Nya produkter kan inte skapas om inte författarna väljer en produkttyp från en nedrullningsbar meny. 

• Sökfältet innehåller ett alternativ för att tillämpa följande ytterligare filter: produkttyp, datum skapat, författare, webbadress och publiceringsstatus. 

• Flera filter kan väljas samtidigt. 

Icke-funktionella krav

• Sökresultaten returneras på mindre än fem sekunder. 

• Sökresultaten är 100 % korrekta. 

7 steg i kravhanteringsprocessen

Kravhantering behöver inte kännas överväldigande. Om du skapar en standardiserad process för ditt team kan du följa samma steg varje gång i stället för att oroa dig för vilka intressenter som ska involveras och när. 

För att hjälpa dig att komma igång har vi förenklat processen till sju steg. När du har provat på och lärt dig vad som fungerar för ditt team kan du anpassa processen för kravhantering därefter. 

Steg 1: Utforma en kravhanteringsplan

Starta ditt projekt genom att skapa en kravhanteringsplan. Planen är din översikt för att hantera krav under hela projektets livscykel. I din kravhanteringsplan definierar du följande:

• Vilka ska vara delaktiga i kravhanteringen?

• Hur kommer du att samla in och dokumentera kraven?

• Vilken är din process för att spåra kravändringar?

• Hur säkerställer du att projektet blir framgångsrikt genom att anpassa det till målen?

En bra kravhanteringsplan hjälper ditt projektteam att hålla sig organiserat och på rätt spår under hela utvecklingscykeln.

Steg 2: Framkallning och kravdefinition

Att samla in krav innebär att samla in och definiera projektkraven. Det är ett viktigt steg där du får kontakt med intressenter och kunder för att förstå deras behov från början till slut.

Kravidentifiering

• Engagera intressenter: Träffa dem personligen eller kommunicera asynkront med intressenter. Presentera produkten, funktionen eller initiativet du skapar och fråga vad de behöver för att hjälpa kunderna eller uppnå sina Business-mål.

• Samla in slutanvändarkrav: Om möjligt kan du utföra användartester. Rådgör åtminstone med ditt utvecklingsteam för att få insikter.

• Hantera förväntningar: Förklara att inte alla begärda krav nödvändigtvis kommer att implementeras. Förtydliga att det här är ett informationsinsamlingsstadium.

Definition av krav

Att definiera kraven hjälper till att beskriva alla komponenter som utvecklingsteamet måste åstadkomma för att slutföra initiativet eller produkten. 

• Skriv tydliga, specifika krav baserat på insamlad information.

• Skapa användningsfall för att visa hur användarna kommer att interagera med slutprodukten.

• Se till att varje krav beskriver ett specifikt behov eller en specifik funktion.

Du kan också skapa användarberättelser för varje krav för att formulera vad användarna behöver och hur de kommer att interagera med din produkt eller funktion.

Sedan kan du dela upp användarkraven i mer specifika systemkrav. Allt eftersom kan du behöva samla in ytterligare information från intressenter för att säkerställa att du har tillräckligt med sammanhang för att slutföra varje krav.

Kom ihåg att du i det här skedet av arbetsflödet för kravhantering samlar in potentiella behov och krav. Ditt team kommer att prioritera och välja de viktigaste att följa upp senare i kravhanteringsprocessen.

Steg 3: Analys och validering av krav

Nu är det dags att sortera igenom all feedback och bestämma vilka krav som stämmer överens med dina produkt- och businessmål. I slutändan bör varje krav bidra till ett övergripande Business-mål, som att öka intäkterna, expandera till nya marknader eller förbättra kundnöjdheten. 

Kravvalidering inkluderar:

• Kontrollera att alla tekniska krav är nödvändiga, genomförbara och inte strider mot varandra.

• Bekräfta att de tekniska kraven är i linje med projektmålen.

Validera sedan kraven med intressenterna. Det innebär att kontrollera att kraven verkligen återspeglar intressenternas behov från början till slut.

Steg 4: Fastställ en utgångspunkt för kraven

När kraven har validerats ska du fastställa en referens. Dokumentationen i det här skedet ger en ögonblicksbild av alla godkända krav och erbjudanden:

• En utgångspunkt för lösningen för kravhantering.

• En referens för framtida beslutsfattande och mätning av förändringar.

Det finns inte bara ett sätt att dokumentera och spåra krav. Ditt produktteam kan tidigare ha använt en programvarukravspecifikation (SRS), ett produktkravdokument (PRD) eller en kravspårbarhetsmatris (RTM). 

Men för att säkerställa att teamet har insikter i realtid om alla projektkrav kan du använda ett projekthanteringsverktyg som Asana. Det betyder att du inte längre behöver föråldrade kalkylark för att granska krav – i stället kan både ditt team och intressenterna se de mest aktuella beskrivningarna av varje krav. Du kan också spåra statusen för varje krav medan du arbetar med projektet och till och med ställa in automatiseringar för att varna intressenter när framsteg görs.  

Du kan också integrera Asana med mer specialiserade appar och verktyg för kravhantering såsom Jira och GitHub. Det är särskilt användbart om du arbetar med intressenter som inte har behörighet att komma åt utvecklarverktyg. 

Steg 5: Prioritering och kartläggning av beroenden

Nu när du har skrivit ner dina krav kan du arbeta med ditt team för att prioritera och planera hur ni ska ta itu med dem. Den här prioriteringen gör att ni kan ta itu med de viktigaste uppgifterna först, särskilt om de blockerar andra uppgifter längre fram.

I det här steget identifierar du hur kraven är relaterade till varandra. Den här processen, som ofta kallas spårbarhet, innebär att:

• Länka samman relaterade krav.

• Koppla krav till andra projektdelar såsom designdokument och testfall.

Om teamet använder agil arbetssätt kan du lägga till kraven i produktbackloggen och sedan hålla ett sprintplaneringsmöte för att bestämma vilka uppgifter som ska ingå i nästa sprint. Om ni inte arbetar i sprintar går det bra att skapa en projekttidslinje för att visa när varje krav ska vara slutfört och om det finns några beroenden. 

Steg 6: ändringshantering, versionskontroll och konsekvensanalys

Kravhantering handlar inte bara om att planera krav innan projektet startar, det handlar också om att hantera förändrade krav under projektets gång. Det innebär att du bör planera hur du ska införliva ytterligare uppgifter som påverkar projektomfattningen. 

Kraven kan ändras under projektets gång. Hantera de här ändringarna genom att:

1. Skapa en process för att skicka in och granska ändringsförfrågningar.

2. Analysera hur varje föreslagen ändring kan påverka andra krav och projektaspekter.

3. Uppdatera din baslinje om ändringar godkänns.

Använd din karta över beroenden för att utföra en konsekvensanalys. Det hjälper dig att förstå den fullständiga effekten av ändringar innan du bestämmer dig för att implementera dem.

Ett annat alternativ är att skapa en process för ändringskontroll. Det ger intressenterna ett sätt att skicka in nya krav som påverkar projektomfattningen, och det avgör vem som ska godkänna eller avslå förfrågningarna.

En väldefinierad process för ändringshantering hjälper dig att förstå hur du hanterar krav effektivt samtidigt som du håller koll på ändringar. 

Steg 7: Systemverifiering och validering

I det sista steget kontrollerar du att din färdiga produkt uppfyller alla tekniska krav:

• Verifiering: Testa varje funktion för att säkerställa att den fungerar enligt kraven.

• Validering: Kontrollera med intressenterna att produkten uppfyller deras behov och förväntningar.

Det här steget hjälper dig att upptäcka eventuella problem innan produkten slutförs, vilket minskar behovet av kostsamt omarbetande senare.

Under hela processen kan du överväga att använda en programvara för kravhantering såsom Asana. Den kan fungera som en central referenskälla och hjälpa dig att hantera krav, spåra ändringar och skapa rapporter och paneler för bättre projektöversikt.

Verktyg för att effektivisera kravhantering

Kravhantering har många rörliga delar, men det behöver inte vara omöjligt att hantera. Med rätt verktyg kan du skapa en upprepningsbar process som visar exakt vem du ska prata med, när du ska göra det och hur du dokumenterar och organiserar kraven under hela projektets livscykel. 

Om du spårar krav i Asana kan du skapa en standardiserad mall som hjälper dig att hantera krav för varje projekt. Det innebär att du kan återanvända ett fördefinierat arbetsflöde i stället för att starta processen från början varje gång, och du kan vara lugn i förvissningen om att du inte glömmer några viktiga delar. 

Vanliga frågor: kravhantering

Vad menas med kravhantering? Kravhantering är processen för att definiera, spåra och kontrollera projektkrav under hela utvecklingslivscykeln. Det säkerställer att alla intressenter förstår och är överens om projektets behov.

Vad är en kravhanteringsplan? En kravhanteringsplan beskriver hur krav ska samlas in, spåras och hanteras under ett projekt. Den fungerar som en guide för att hantera ändringar, dokumentation och kommunikation.

Vilka är de viktigaste funktionerna i kravhanteringsprocessen? De viktigaste funktionerna i kravhanteringsprocessen är att samla in krav, analysera och validera dem, spåra ändringar och säkerställa att slutprodukten uppfyller de överenskomna kraven.

Hur ser ett bra krav ut? Ett bra krav är tydligt, specifikt och mätbart. Det bör vara lätt att förstå, testbart och i linje med projektets övergripande mål.