Från risk till design

Risker finns överallt! En del av dem gömmer sig i specifikationer och dokumentation inom ett projekt. Jag pratar här om otydligheter som göms i odefinierade begrepp och i textuella strukturer som ser bra ut på ytan, men som vid en närmare betraktelse visar sig dölja antaganden och halvsanningar1.

Låt oss titta på ett litet konstruerat exempel.

Situationen är den att du hittar följande fras i den tekniska specifikationen för en ny filminspelningsprodukt:

Nu hajar varje kravingenjör till och kan inte sitta still och vara tyst, eller hur?
Frasen ovan känns som en ”brasklapp”, en friskrivning som glidit med i specifikationen utan att tas om hand på ett korrekt sätt. NÅGON är tydligen oroad över outtalade och troligtvis krockande antaganden (Assumptions). Temperaturbegränsningarna på strömförsörjningsenheten (”The battery pack”, ännu ett antagande!) och den faktiska miljön som kameran kommer att användas i (System Context)2.

Om vi samlar in ”the Assumption Sheep” och ”put a fence around them” d.v.s. identifierar alla antaganden, synliggör dem och formulerar dem, så angriper vi de gömda riskerna på ett effektivt sätt.

Vissa antaganden kanske borde verifieras men framförallt måste vi adressera dem så att de inte fastnar gömda i en specifikation.
Ett alternativ är att skriva ett antal varningar i användarmanualen. Men handen på hjärtat, vem läser manualer numera? Dessutom lär inte användarna bli speciellt glada om produkten inte fungerar när de väl behöver den, och varningarna i manualen hjälper föga i stunden. Missnöjda kunder!

Ett bättre sätt är att skapa verksamhets-KRAV som fångar in riskerna.  
Vi kastar ihop en enkel kravtext3:

Verksamhetskravet är skapat efter insikt om den verkliga användningen av produkten i dess rätta miljö med de tänkta användarna.

Tillsammans med de explicita antagandena leder verksamhetskravet troligtvis till en ny design.

Förslag på nya sätt att tänka är exempelvis:

  1. 1.     designa helt nya batterier som tål kyla
  2. 2.     förbättrad isolering av batteripaketet
  3. 3.     uppvärmning av batteripaketet
  4. 4.     annan strömkälla än batterier
  5. 5.     batterierna bärs innanför käderna och endast kameran utsätts för kylan

Alla nya designidéer kommer givetvis ge upphov till nya antaganden och specifika krav.

Gömda antaganden är potentiella risker för projektet och produkten.
Vi måste förstå användaren och hur och i vilken kontext som produkten kommer att användas.
En bra lösning skrivs inte in i en manual, den designas in i produkten

[1] Inom IREBs certifiering CPRE (Certified Professional for Requirements Engineering) handlar hela kapitel 5 om ”Krav och Naturliga Språk”, vilket gör att du får en helt ny syn på text och naturligt tal.

[2] Ett annat kapitel i CPRE-kursen: ”System & Context Boundaries”

[3] Hur man skriver ett effektivt verksamhetskrav är INTE en del av denna artikel, utan här kastar vi fram en första version av en kravtext utan alla andra kravattribut som Rational, Conditions of Satisfaction etc.


Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.