En elefant i rummet

Hej Branschen,

Jag är inte helt säker, men jag tror att det står en elefant i rummet! Ni vet en sån där jobbig grej som alla vet finns men som ingen vågar nämna för man är inte säker på att de andra ser den. Jag ser den i alla fall. Jag ska beskriva den, så får vi se om ni också tycker att det är en elefant, eller om det kanske bara är en dammråtta.

Elefanten jag pratar om är det här med terminologi för kravhantering. I vårt arbete svänger vi oss med en massa fina ord för att beskriva saker och utgår från att alla andra förstår vad vi menar. Men är det alltid så? Nej, självklart inte. Efter 10 år som kravhanterare har jag kommit att inse att många av oss faktiskt använder ord väldigt olika.

cartoon-elephant-md

Ta ordet krav t.ex. Det är ju ganska centralt för vår verksamhet. En av de viktigaste egenskaperna för ett krav är att det inte ska gå att misstolka. Ändå är själva ordet krav ett av de ord som har flest tolkningar i svenska språket. För en del har det med indrivning av pengar att göra. För andra handlar det om ekologisk mat.

För ytterligare några (oss) handlar det om något som talar om vad något annat ska göra eller vara. Men ändå är det inte självklart hur ordet ska definieras. Vissa menar att det är synonymt med något som systemet/produkten ska kunna göra eller vara (typ ”feature”). För andra handlar det om att formulera vilket värde som ska skapas för någon och för vissa handlar det helt enkelt om att skriva ner tekniska beskrivningar som sedan ”bara” ska omvandlas till fysisk form. När jag föreläser ställer jag ibland frågan vad ordet krav innebär för deltagarna och jag brukar få lika många svar som det finns deltagare.

En annan förvirring finns runt begreppet funktion. För några månader sedan föreläste jag på en konferens och pratade bl.a. funktionella krav. En av de andra föreläsarna rättade mig då och påpekade att alla krav ju borde vara funktionella, och det jag menade var säkert funktionskrav. Man kan iofs tycka att detta är hårklyverier, men han hade faktiskt en viss poäng. Jag började också fundera på om inte själva ordet funktion används olika på olika ställer så jag gjorde lite efterforskning.

Inom IT-branschen finns det massor av definitioner av ordet funktion. En vanlig sådan är något i stil med ”En funktion är en beskrivning av något som systemet gör”. Ibland finns det en sammanblandning mellan tekniska lösningar och rena funktioner. Distinktionen kan ibland vara svår men i stort är nog de flesta i IT-branschen överens om vad en funktion är.

I andra branscher är det inte lika självklart. T.ex. definieras funktion i bygg- och anläggningsbranschen som ”Sådan användbarhet eller sådan för användbarhet nödvändig egenskap, som normalt konstateras genom mätning, provning eller nyttjande”. Detta är mycket bredare och implicerar att man även inkluderar prestanda och andra krav som traditionellt brukar kallas för icke-funktionella krav (förkortar det IFK nedan).

När det gäller just icke-funktionella krav (eller borde det heta icke-funktionskrav?) så finns det ännu mer förvirring. Den största anledningen till det är att det faktiskt inte säger något om vad det är. Icke-funktionella krav säger bara vad det inte är. Många organisationer går numera ifrån att kalla det IFK men det finns ännu ingen vedertagen standard för vad de bör kallas. Själv brukar jag dela upp det i intressentvärde och produktkvaliteter men jag har sett och hört många andra termer som också är bra och rätt.

Poängen, och elefanten i rummet, är att vi har en stor flora av termer som är dåligt definierade och betyder olika saker i olika sammanhang och/eller organisationer/branscher. Vissa försök till standardisering finns men otydligheten är fortfarande stor, tycker jag.

Så. Vad tycker ni? Är detta en elefant eller en dammråtta? Jag vill gärna veta hur ni definierar ert språk kring kravhantering!

Med vänliga hälsningar

Alexander, Elefantskötare på Require AB

4 reaktioner till “En elefant i rummet”

  1. Underbart!
    En annan aspekt på krav är när de kommer in i bilden. Ta en snabel som exempel, ett ytterst funktionellt verktyg för en mängd användningsområden. Det är lätt att komma på en massa krav för en snabel, men vem skulle kunna tänka ut en på förhand?

    Ofta ses kravhantering som ett uppsamlingsheat för att på ett systematiskt sätt komma vidare efter en kreativ fas – och innan det roliga börjar med själva byggandet. På något sätt lite tråkigt, eller? Kanske inte. Det är ju också så att när kraven blir skarpt ställda, när målen sätts högt så är det alltid någon som kommer på den där brillianta idén!

    Håkan snabel-a Frontreport

    1. Absolut! Kravhantering kan ju vara otroligt inspirerande för kreativiteten. Då är det ju dock viktigt att man specar just krav, och inte lösningar.
      Som du skriver är det ju också viktigt att man börjar tidigt med kraven.
      Var tredje formellt fel i hur kraven är skrivna och strukturerade leder till någon form av defekt i produkten. Värt att tänka på när man skyndar igen kravprocessen.

  2. Yes! Och är det inte lite skönt att kravproffs är lika goda kålsupare som alla andra, med sin alldeles egna interna jargong. Jag ruvar på en ganska outvecklad tanke om att krav- och informationsmodeller i större utsträckning borde kunna användas till att märka upp (till skillnad från att eliminera) homonymer och andra vanskliga begrepp, i syfte att hjälpa både systembyggare och -användare att sakta in och köra lite varsamt över dessa språkliga farthinder.

    Hur många procents genomsnittlig utvecklingstid, mötestid etc tror vi att begreppsförvirringarna står för? Jag skulle höfta på i alla fall någon procent av BNP, dvs en marknad värd i storleksordningen 50 mdr bara i Sverige.

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *