Den meningslösa kravmodellen

Man kan ställa sig frågan varför man till varje pris vill ha en kravmodell av det system man just har byggt? Kanske är det så att analogin med husbyggnation fortfarande regerar. Vem kan tänka sig att bygga eller köpa ett hus som inte har ritningar in i minsta detalj. Förmodligen ingen. Men varför tror man att det måste vara så för ett IT-system? Om man kunde specificera ett IT-system på samma sätt som ett hus så skulle det radikalt förenkla IT-projektens komplexitet och i stort eliminera risk. Varje projekt skulle estimeras nära nog perfekt, alla aktiviteter planeras med precission och leveransen skulle ske på exakt rätt dag. Kanske en lätt överdrift men ni förstår säkert vad jag menar. Skillnaden på angreppssätt mellan att å ena sidan bygga något som med exakthet kan räknas på i förväg och vars komplexitet bygger på kända fysikaliska lagar och å andra sidan ett IT-system, är ljusår emellan. De båda kräver helt enkelt olika utvecklingsmetoder för att bli framgångsrika.

Någon som sett en användningsfallsmodell som efter ett IT-projekt har varit synkroniserad med den implementerade koden? Räck upp en hand i så fall!

Min gissning är att de flesta sitter kvar med händerna utefter sidorna, kanske t.o.m. alla. Det är en ovanlig företeelse som jag personligen aldrig har upplevt. Vid ett flertal tillfällen har jag däremot varit med om absurditeten att man som sista desperat åtgärd försöker "rätta till" kraven utefter vad som har implementerats. Utan att helt lyckas förstås.

Vad är då nyttan med kravdokumentation? En del hävdar med bestämdhet att det är viktigt att se hur systemet fungerar. Ser man inte det genom att använda det? Jo, ok men det är viktigt att se hur systemet ska fungera. Jaha, ok men vad gör man då om kraven inte stämmer med vad som är implementerat? Vilken är korrekt? Kraven eller koden? Vad är värdet av kravdokumenten i ett sådant läge? Ska man ändra koden eller ska man ändra i kraven?

Lösningen är ett testdrivet angreppssätt där kraven används som startpunkt för utveckling och inte som facit. Samarbete mellan beställare, testare och programmerare formar successivt systemet genom testdriven utveckling. Projektet kommer inte att leverera en modell av systemet, men väl ett fungerande och användbart verkligt system.

Om författaren
Mats Wessberg är VD och medgrundare av Inceptive. Han har verkat i IT-branschen sedan 1995 och mestadels som konsult. Hans huvudsakliga expertis är inom Quality Management och utvecklingsmetodik.