Tekniker för att prioritera krav

2005-03-15 Artikelbanken Kravhantering Läst 10930 gånger

Prioritering handlar om att hitta de mest betydelsefulla kraven eftersom det aldrig finns tillräckligt mycket tid för att uppfylla samtliga krav. Många känner att de gör prioritering baserat på sin maggropskänsla och att metoderna inte alltid är helt genomtänkta. Användare och beställare känner ofta att prioriteringen innebär att man måste prioritera allt som ”viktigast” eftersom lägre prioriterade krav aldrig kommer att införas – de hamnar i en restlista som aldrig tycks krympa. I den här artikeln beskriver jag två vanligt förekommande tekniker för att prioritera krav.

Det finns flera anledningar till att det viktigt att göra rätt prioriteringar.

  • För projektets ledning är prioriteringen en värdefull hjälp vid planeringen av vilka funktioner som ska levereras i vilken version av systemet.
  • En systematisk prioritering gör det lättare för systemägare projektledare att tilldela rätt resurser. Ett viktigt krav kan ges fler resurser endast om man vet att det är ett viktigt krav.
  • För utvecklaren eller leverantören tjänar prioriteringen syftet med att visa vad kunden prioriterar högst. Detta gör det enklare att lägga tiden på de funktioner som behövs först.

Vanliga prioriteringstekniker

De flesta använder något slags värdeskala vid prioritering, t ex ”hög”, ”medel”, ”låg” eller ”skall” och ”bör”. Ett angreppssätt är att gå igenom alla kraven och för varje krav ange vilken prioritet kravet har. Om kravens rubriker skrivs in i Excel eller ett kravhanteringsverktyg som exempelvis Konsultbolag1:s ReQtest, kan man gå igenom kraven ett och ett. Vilka personer som deltar i prioriteringsarbetet varierar från företag till företag och mellan olika projekt, men det är vanligt att prioriteringen görs av personer från beställarorganisationen.

Prioritering med värdeskala kan göras både i grupp och individuellt. Om många personer ska delta i prioriteringsarbetet, fungerar tekniken ”tre pinnar” bra. Sätt upp kraven på en tavla i konferensrummet och låt varje person dra ett streck intill de krav som denne prioriteras allra högst. Det är viktigt att kraven är av den karaktären att det är möjligt att prioritera dem mot varandra om denna teknik ska användas. Det går exempelvis inte att prioritera ”hög säkerhet” mot kravet ”det ska vara möjligt att spara kunder” eftersom det är två helt olika sorters krav. Däremot går det att prioritera kravet ”möjlighet att spara kund” i förhållande till ”avancerad sökfunktion”.

Ofta när jag hjälper en kund med att ta fram en kravspecifikation hittar jag krav som ska införas senare men inte just nu. Dessa markerar jag som ”framtida krav” i kravspecifikationen. Detta gör att utvecklaren inte målar in sig i ett hörn genom att bygga funktioner som senare måste byggas om trots att vi på beställarsidan har förutsättningarna klara för oss. Jag kan exempelvis markera funktionen ”avancerad sökfunktion” som ett framtida krav i det fall jag nöjer mig med en enklare sökfunktion i den version av systemet som planeras nu. Om utvecklaren som läser kravet ser att den avancerade sökfunktionen endast innebär litet merarbete, kan vi diskutera att införa funktionen redan nu för att minimera onödigt dubbelarbete.

För- och nackdelar med värdeskala

Det går mycket snabbt att göra prioritering med hjälp av någon av skalorna ovan. Utan stora problem kan 30-40 krav prioriteras på mindre än en timme och ofta mycket snabbare än så. Enkelheten är dock teknikens begränsning. En grupp beställare tenderar att prioritera alla krav som ”högsta prioritet”. Värdeskalan är också subjektiv, ett krav som du tycker är viktigt, kan uppfattas som oviktigt av någon annan.

Det största problemet med värdeskala är att den inte tar hänsyn till utvecklingskostnaden. Av de krav som har ”högsta prioritet” kommer vissa krav ta några få timmar eller dagar att genomföra och andra krav kan ta åtskilliga veckor. I en situation med tidsnöd då man måste välja vilka av kraven som ska realiseras, krävs information om hur lång tid kraven tar att realisera för att kunna fatta vettiga beslut. Här kommer därför en teknik som löser detta problem.

Prioritering mot två kriterier

Ett bättre sätt att prioritera krav är att använda två olika kriterier, exempelvis både kostnad för utveckling och värde för användarna. Andra tänkbara kriterier är värde för beställarna (dessa behöver inte göra samma prioriteringar som användarna) och teknisk risk, det vill säga svårighetsgrad eller risk att en ändring leder till negativa konsekvenser på andra delar av systemet. Beställarorganisationen kan bedöma värde för användare och värde för beställare precis på samma sätt som när en värdeskala används. Teknisk risk och kostnad ska däremot bestämmas av leverantören. För att göra detta effektivt, kan man ställa upp alla krav i en tabell enligt nedan.

De första två kolumnerna fylls i och sedan får beställarna komma fram till värde för användare samtidigt som leverantören får uppskatta utvecklingskostnad.

ID Rubrik Värde för
användare
Utvecklings-
kostnad
1 Lista samtliga ärenden 4 3
2 Enkel sökfunktion 4 2
3 Avancerad sökfunktion 2 3
4 Möjlighet att spara varje sökning 1 4

Skalan som används är påhittad, den går från 1-4 där 1 betyder minst viktigt för användarna respektive lägst utvecklingskostnad och 4 är viktigast respektive högst kostnad. Om du tycker att skalan är för grovmaskig, kan du använda en skala med 6 eller 8 steg i stället. Fler skalsteg gör det lättare att analysera resultatet men svårare att fastställa korrekt värde.

När både beställare och leverantör har fastställt värden i de två kolumnerna kan man använda ett program som Excel för att sortera fram de krav som har högst värde för användarna samtidigt som det har lägst utvecklingskostnad. Dessa krav bör införas så snart som möjligt i systemet. Det går även enkelt att hitta de krav som kostar mycket att lösa samtidigt som de prioriteras lågt av användarna - dessa krav ska inte införas nu, kanske ska de inte införas alls. Om en värdeskala hade använts, skulle dessa krav inte ha upptäckts på något enkelt sätt!

Avslutningsvis

Vid all prioritering bör man exkludera krav som inte är möjliga att prioritera. Det kan exempelvis vara krav på funktioner som skulle göra systemet meningslöst om de inte infördes. Tänk dig ett ordersystem där det inte går att lägga in beställningar. Det kan även vara funktioner som måste finnas på grund av lagkrav, interna krav från t ex IT-avdelningen och krav som måste uppfyllas för att certifiera produkten enligt något regelverk. Dessa krav går inte att prioritera och ska därför inte finnas med.

Det är viktigt att ha inställningen att den prioritering som görs ska ligga till grund för den kommande utvecklingsetappen. Det går med andra ord inte att göra en enda prioritering för samtliga leveranser på en gång. När en utvecklingsetapp börjar lida mot sitt slut, görs prioritering igen inför den kommande perioden. Detta eftersom vissa krav som bedömdes som viktiga initialt ofta försvinner under resans gång samtidigt som nya krav kommer att dyka upp.

Kontakta mig gärna om du har några frågor om prioritering av krav!

Tips för vidare läsning

  • Boken kravhantering för IT-system av Ulf Eriksson.
  • Faktabanken innehåller kostnadsfria dokument inom test och krav.
  • Se även vårt kursutbud.

 

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln