På Agile Swedens mejllista har det pågått en liten diskussion om ordet ”krav”. Är det något vi vill använda? Om inte, vad kan vi ersätta det med? Ordet ”behov”? Här är min syn på saken.

Idé: Ersätta ”krav” med ”behov”

Ordet ”krav” har sina rötter i upphandling efter fix kravspecifikation och är alltså ett ord som vi snabbt förknippar med systemutveckling enligt vattenfallsmodellen. Eftersom vi vet att namn på saker och ting är oerhört viktiga och detta ord är behäftat med ett ansenligt och missledande arv kan det vara värt att undersöka alternativa sätt att formulera sig.

Det jag personligen har landat i, vilket även diskussionen på mejllistan landade i, var ordet ”behov”. Det vi egentligen försöker göra är att uppfylla ett behov. Behov sätter associationen klockrent till användarna av systemet och därmed nyttan eller värdet med en eventuell lösning för att uppfylla behovet. Behov lider inte heller av det obehagliga arv som ”krav” gör. Därför bör ”behov” ersätta ”krav” i agila sammanhang.

Varför ”behov” inte (alltid) fungerar

Problemet är att det inte riktigt fungerar. Om man konsekvent försöker ersätta ”krav” med ”behov” är det något som inte riktigt känns rätt i magen. Lyssna på följande meningar. Låter de bra?

• Detaljeringen av behov sker parallellt med utvecklingen. (Njae, vi detaljerar väl inte precis behoven…)
• Vad har du, kära produktägare, för behov angående funktion X? (Eh, vi vill nog veta mer detaljer om behovet.)
• Acceptanstesterna verifierar att kundens behov är uppfyllda. (Gör de verkligen det?)

Problemet som uppstår, i alla fall för mig, är att behov och krav redan har tydliga betydelser som visserligen är överlappande, men inte synonyma. Jag hade en givande konversation med Sara Manding om detta och vi kunde snabbt identifiera tre tydliga skillnader mellan behov och krav:

1. Behov är ofta specifika för en användarroll medan krav vanligen inte är det. Meningen ”Journalister kan hitta telefonnummer till anställda” uttrycker ett behov hos en av våra användarroller medan ”Det ska gå att söka telefonnummer till anställda” inte gör det.
2. Krav implicerar ofta en tänkt lösning. Meningen ”Journalister kan hitta telefonnummer till anställda” är helt lösningsneutralt medan ”Det ska gå att söka telefonnummer till anställda” implicerar att vi ska utveckla någon slags sökbaserat lösning.
3. Behov kan finnas på en marknad eller hos en användargrupp utan att vi känner till dem. Marknaden kanske inte själv kände till den. Tror någon på allvar att iPhone utvecklades genom att några användare sa att ”de kände ett starkt behov av en ny typ av digital manick med en massa grymma appar men som också gick att ringa med och med innovativa designlösningar i användargränssnittet”? Likväl känner folk ett starkt behov av att vilja äga en. Krav innebär oftast att vi redan tror oss ha identifierat något som beskriver hur vi vill utforma vår lösning.

Ett reviderat förslag

Mitt (reviderade) förslag för hur vi kan säga:

1. Använd ordet ”behov” för arbete som bereder iterationsplanering och för det som ligger i en produktrestlista (”product backlog”). Då är det verkligen behov vi arbetar med. Dels när vi med användarworkshops, intervjuer, enkäter, användbarhetstester och annat försöker identifiera och formulera behov hos våra målgrupper. Dels när vi masserar och prioriterar bland dessa behov som kandidater för vilka vi ska utveckla lösningar i kommande iteration.
2. För arbetet som pågår i iterationen och som utgår från behoven skulle jag föreslå ”acceptanskriteria”. Det är ju det vi kallar de punkter som våra produktägare ska uttrycka för att vi ska veta att vi är klara med en story. Det är de punkter som vi skriver specificerande tester (exempel) för. Det är de som är startpunkten för TDD/BDD.

Till skillnad från ”behov” fungerar detta ord utmärkt i våra tidigare meningar:

• Detaljeringen av acceptanskriteria sker parallellt med utvecklingen.
• Vad har du, kära produktägare, för acceptanskriteria angående funktion X?
• Acceptanstesterna verifierar att kundens acceptanskriteria är uppfyllda.

Ett alternativ till ”acceptanskriteria” som jag vill ta upp, är ”mål”, som Joakim Ohlrogge föreslog på mejllistan. Mål ska ju vara specifika, mätbara och realistiska precis som acceptanskriteria. Det har också fördelen av att det är enklare. Möjligen låter det lite för generellt för våra syften.

En nygammal användning av ”krav”

Men ”krav” då? Är det ett meningslöst ord som bör relegeras till det förflutna. Det tycker jag inte. Jag föreslår i stället att vi låter ordets betydelse återgå till den ursprungliga, den som vi alltid har menat tidigare: Något som måste vara oåterkallerligt uppfyllt. Det finns alltså behov som är krav (men inte så många som vi tror). Krav är behov som måste vara uppfyllda för att vårt system ska ha en mening. Dessa behov delas ofta bland alla användarroller. I en digital telefonbok är det ett behov och ett krav att kunna hitta telefonnummer. Systemet saknar mening annars. Att även kunna hitta information om e-postadress är troligen ett behov men säkert inget krav.

Det här kanske låter självklart, men jag tror att vi är förvirrade angående krav. Och jag tror att det är vår envisa strävan att kalla allt i en kravspecifikation för ”krav” som gör oss förvirrade. Att ha ord som ”bör-krav” är en självmotsägelse. Det kanske inte är så konstigt att vi blir förvirrade.