Krav

Kravhantering handlar om att fånga behov, möjligheter och affärsvärde för att sedan omforma dessa till verifierbara systemförändringar. Utmaningen ligger i kommunikationen som skall formulera ett bra resultat (med högt affärsvärde) och ge alla inblandade, med olika kompetenser och bakgrund, samma bild av det förväntade resultatet.

Hur vi bedriver kravhantering påverkar och påverkas av i stort sett allt annat arbete som bedrivs inom system- och mjukvaruutveckling.
Vi behöver skapa en balans i informationsflödet.
En balans mellan olika intressenters behov, en balans mellan dokumentation och aktiv dialog,
en balans mellan framåtriktad information för
att realisera nya värden och bakåtriktad för att bevara befintligt värde, en balans mellan beslut och förändrings-benägenhet, en balans mellan förväntningar och realiserad lösning.

Vad är det bra till?

Oavsett om kravinsamlingen sker iterativt i samband med att produkten byggs på eller huvudsakligen görs innan utveckling så är syftet och arbetet detsamma. Skillnaden ligger i volymen av information som hanteras och tiden från att informationen definieras till dess att den används. Det är ingen skillnad att förringa - den är avgörande för hur komplex hanteringen behöver vara, t ex hur mycket som kan hanteras verbalt istället för skriftligt.

I agila utvecklingsmetoder används huvudsakligen två åtgärder för att förenkla kravhanteringsproblematiken – kundrepresentant på plats hos utvecklingsteamet och korsfunktionella team. På så sätt minskar risken av missförstånd både mellan kund och utvecklingsteam samt inom utvecklingsteamet. I dokumentstyrda utvecklingsmetoder fokuseras det istället på ett antal mellanresultat i form av dokument eller modeller där olika roller steg för steg förädlar krav till system. I båda fallen är förståelsen av kraven och dess bakgrund vitala för alla inblandade.

Utmaningar

Det finns många utmaningar inom kravområdet men de kan huvudsakligen kopplas till någon av tre:

  • Hitta rätt krav. De flesta organisationer är beroende av insatta och kompetenta individer som förstår slutanvändarnas situation och affärsprocessen. Problem uppstår ofta då dessa personer byts ut eller då nya produkter skall tas fram. Ett annat problem är att vad som är rätt förändras med tiden.
  • Undvika missförstånd. Speciellt när många olika intressenter från olika grupperingar är inblandade så är det svårt att undvika olika uppfattningar av vad kraven betyder. Även inom utvecklingsteamet kan missförstånd av vad kraven innebär skapa problem.
  • Underlätta för resten av utvecklingsteamet. Att formulera krav så att resterande utvecklingssteg underlättas kräver förståelse för det arbetet. Detta är speciellt problematiskt om kravarbetet görs tidigt och möjligheten till direkt kommunikation vid implementation är begränsad.

Lika vanligt som att krav dokumenteras för dåligt är att krav överdokumenteras och att det därmed smyger sig in beskrivningar som inte bidrar till det önskade affärsvärdet.

Vad är det?

Definitionen av vad kravhantering är skiftar en del men här är en del områden som ingår eller är angränsande:

  • Kravinsamling – att genom intervjuer, observationer, mätningar och analyser samla in krav, behov och förväntningar hos olika intressenter.
  • Kravprioritering – att avgöra vilken affärsnytta som finns i olika krav eller grupperingar av krav och vilka beroenden som finns kopplade till dem.
  • Kravförädling – att utifrån insamlade kundkrav utforma relevanta systemkrav och avgöra vilka krav som är relevanta för vilka delsystem
  • Kravverifiering – att avgöra om olika krav är motsägelsefulla eller på annat sätt inte är kompatibla med produkten eller projektet. Ett sätt är att vara SMART.
  • Kravvalidering – att avgöra om kraven kommer att uppfyller syftet bakom kravet och ge det efterstävade affärsvärdet.
  • Intressenthantering – hantering av olika intressen i produkten och förväntningar på kommande versioner av produkten.
  • Kravdokumentation – form, volym och livslängd av dokumentation och hur den kompletteras med annan form av kommunikation.
  • Ändringshantering – hur ändringar av krav hanteras under deras livslängd.
  • Produktdokumentation – hur mycket av kravinformationen är relevant att ha kvar under produktens livscykel.

Den enklaste åtgärd som kan göras för att förenkla kravhanteringsproblematik är att minska mängden krav som det arbetas på genom kortare iterationer och fler releaser. Det finns även ett antal verktyg som hjälper till att strukturera arbetet och hålla ordning på beroenden och spårbarhet. Några är Doors, Rational RequisitePro, CaliberRM och Rational Focal Point.

Det finns också ett antal kravmodelleringsmetoder och dokumentationsformat. Ett av de vanligare är användningsfall ("Use Case") som tydligt klargör gränsen mellan användare och system och som är relativt läsbart även för icke-tekniker.

Var kommer det ifrån?

Kravhantering är ett ämne som vi inom mjukvaruindustrin ärvt från andra ingenjörsgrenar. En stor skillnad jämfört med t ex tillverkningsindustri är att vi inom produktionen av mjukvara har förmågan att göra ändringar sent i produktionsledet. När denna förmåga nyttjas flitigt blir traditionella kravhanteringsprocesser ansträngda.

Vår erfarenhet

Kravhantering är en form av kommunikation och därför beroende av de människor som deltar i kommunikationen. Även en väl fungerande kravhantering kan påverkas allvarligt av personalförändringar eller andra förändringar som ny produkt eller nya kunder/intressenter. Addalot har lång erfarenhet av hur kravhantering anpassas för olika situationer och dess påverkan på andra processer inom systemutveckling.

Läs mera

På Wikipedia finns en hel del att läsa om krav och kravhantering:

Vi kan också rekommendera följande böcker:

  • Writing Effective Use Cases av Alistair Cockburn [Bokus.com]
  • Requirements Engineering av Ian Sommerville, Pete Sawyer [Bokus.com]