Hur många krav är för många?

Många gånger får jag frågan om hur få/många krav man bör ha i sitt projekt. Det är en fråga som är väldigt svår att svara på. Alternativt blir svaret något så luddigt som ”precis lagom många”. Jag är dock av den bestämda åsikten att alldeles för många projekt specificerar på en alltför detaljerad nivå. Det går inte att styra efter hur mycket som helst. För många krav gör att det blir omöjligt att vara effektiv. Konsten är att kunna skapa en modell av vad som ska utvecklas med precis sån detaljnivå att alla förstår. Det får varken bli så mycket att alla drunknar i krav i onödan och det får inte bli en så förenklad bild att den inte är användbar.

Jag läste för ett tag sen en artikel om modellering och den tog upp ett väldigt bra exempel. Om man säger att jorden är platt har man fel. Om man säger att jorden är rund har man egentligen också fel (den är trots allt inte helt rund), men ändå nog rätt för att skapa en mer tydlig bild av hur jorden ser ut. Det finns inte mycket värde i att ge en lång utläggning om jordens exakta form (i de allra flesta fallen åtminstone).

Samma sak gäller detaljnivån i kravspecifikationen. Det gäller att beskriva systemet/produkten på en nivå så att allt som står i den skapar nog mycket värde för läsaren att det är värt att lägga ner tiden på det. Det är såklart en bedömningsfråga från projekt till projekt och fall till fall, men man bör alltid ha värdeskapandet i åtanke när man skriver krav. Är det inte bättre att på ett snabbt och effektivt sätt skapa 98% av det möjliga värdet istället för att lägga den dubbla tiden på att nå 99,9%? Går man mot 100% går man också mot oändligheten vad gäller resursanvändning. Perfektion är sällan värt att betala för. Missförstå mig dock rätt. För lite definition är också farligt och bör absolut undvikas. Jag tror dock att många projekt skulle må bra av lite färre, men bättre skrivna, krav.

/Staffan Melin, Require AB