När vi nu för tiden utvecklar IT-system så gör vi det ofta utifrån en förståelse för hur lösningarna faktiskt ska användas samt hur de påverkar verksamhet och organisation.
Och det är bra.
Problemet är bara att vi lätt glömmer bort systemet i vår iver att förstå verksamhetens behov. Det gör att vi ibland inte har koll på hur våra system är tänkta att fungera och bete sig. På senare tid har jag allt oftare stött på detta problem vilket bland annat resulterar i problem med att bibehålla kvalitet i systemen över tid eftersom det är svårare att förvalta och vidareutveckla något som man inte riktigt förstår sig på.
Behövs långsiktiga system
Missförstå mig inte, jag tycker det är viktigt att förstå vilka värden en lösning ska leverera åt verksamheten och vilka krav verksamheten har på exempelvis processerna som genererar värdet. Det gör att IT får förutsättningar att kunna leverera lösningar som på ett effektivt sätt stödjer verksamheten. Men vi vill samtidigt inte ha system som går sönder efter ett tag eller blir omöjliga att vidareutveckla.
Fram till för ungefär tio år sedan försökte vi som arbetade med krav specificera systemkrav som skulle stödja verksamheten utifrån vår roll som systemanalytiker i de IT-organisationer vi arbetade i. Problemet var ofta att det inte fanns motsvarande roll inom verksamheten, och även om vi specificerade och byggde bra lösningar så var det inte alltid de lösningar som verksamheten behövde. Från vårt IT-perspektiv såg vi bara IT-delarna av lösningen och ingen såg till helheten.
Med tiden insåg många organisationer problemet och skaffade sig verksamhetsanalytiker. Flera av oss som tidigare kallat oss kravanalytiker eller systemanalytiker började istället kalla oss business analysts. Vi läste BABOK, tog fram processer, begrepps- och informationsmodeller. Vi började intressera oss för vad som hände utanför IT-systemens värld för att försöka få till förändringar som inte bara bestod av IT-system.
Systemkrav har blivit ett skällsord
Enligt min mening har det gått lite för långt. Någonstans på vägen blev systemkrav nästan ett skällsord. Krav skulle bara beskrivas ur ett verksamhetsperspektiv och detaljerade systemkrav skulle vi inte längre lägga tid på att dokumentera. Även om user stories är ett utmärkt verktyg för att utforska krav är det ett rätt uselt format för att dokumentera en lösning.
Resultatet av detta är att man inte har en tydlig bild över hur de lösningar man tagit fram faktiskt ska bete sig. Man har förvisso koll på hur de ska stödja verksamhetsprocesserna, hantera information och vilka verksamhetsregler som gäller men man saknar koll på detaljerna. Det är helt enkelt viktigt att förstå hur ett system ska bete sig även i detalj. Som en liknelse så är detaljerna för hur styrenheten i min bil är konstruerad eller fungerar inte viktiga för mig som bilägare, men för att jag ska kunna få min bil servad så behöver detaljerna vara specificerade och kända av bilverkstan.
På samma sätt har IT-organisationer nästan alltid behov av att känna till detaljerna för hur ett system ska bete sig. Har man inte det så får man lätt problem med att vidareutveckla systemet eller att verifiera att det beter sig som det ska, framför allt när systemet funnits och vidareutvecklats ett tag. Det är inte lätt att komma ihåg alla detaljer i något som utvecklades för länge sedan, och det är ovanligt att de personer som utvecklat systemet finns kvar i en förvaltningsorganisation under ett systems hela livscykel.
Vi borde alltså specificera våra system mer än vad som blivit norm under senare år.
Välj format som passar behoven
Formatet på dessa specifikationer behöver inte vara i form av vad vi normalt kallar systemkrav. Det kan ibland vara tillräckligt med tekniska designspecifikationer, testfall eller något annan typ av systemdokumentation som passar behoven.
Jag tycker inte att dessa systemkrav alltid behöver vara förståeliga för verksamheten. Finns verksamhetskraven beskrivna så kan dessa användas som kontrakt mellan IT och verksamhet. Systemkraven blir då en intern dokumentation för IT som ska passa IT-organisations behov. Och systemkraven ska förvaltas och utvecklas tillsammans med systemet.
Så även om det är bra att vi blivit duktigare på att förstå verksamhetsbehoven bakom den utveckling vi gör får vi inte glömma bort IT-organisationens behov av att på sikt kunna säkerställa kvalitet i de system vi utvecklar och förvaltar. Och för att klara av det behöver vi detaljerade systemspecifikationer.
Jakob Bäckström, konsult och partner Tagore