En sak jag stöter på väldigt ofta är att en stor del av kraven i en specifikation aldrig riktigt valideras av de faktiska intressenterna, det vill säga att kraven verkligen täcker deras specifika behov. Även om mycket tid läggs på själva intressentanalysen och/eller behovsinsamlingen finns det en mängd fel som kan uppstå när behoven omvandlas till faktiska krav. Tolkningar görs, språket används på olika sätt, formuleringar och ord ändras. Det är inte alls säkert att de behov som man så noggrant samlade in nu är fullständigt representerade i den färdiga kravspecifikationen. Resultatet blir ett system som inte motsvarar intressenternas förväntningar.
Det finns såklart förklaringar till varför det blir så här. Det är inte, åtminstone inte i de flesta fallen, så att man ignorerar det med flit. En vanlig orsak är att kravskrivarna hamnar väldigt långt ifrån intressenterna. Ett typiskt scenario är att en organisation samlar in kundbehov och samlar i ett kontrakt som en inköpsorganisation tar emot och sen passar vidare till utvecklingsorganisationen. På så sätt blir ”kundkraven” bara ett kontrakt som ska uppfyllas, krav som är svåra eller omöjliga att ändra på. Avståndet mellan kravingenjör och intressent blir därför alldeles för långt.
Kravingenjörer jag pratar med känner därför att krav är något man inte kan göra så mycket åt. De skriver sina tekniska krav utifrån det kontrakt som finns och inget annat. Kontrakt mellan kund och beställare är inte deras sak att ändra på.
Det är alltså inte bristen på valideringsmetoder det är fel på. Det finns massor av bra metoder, som granskning, tester, modellbaserad simulering, matematiska modeller och annat som hjälper till att ta reda på att kraven är korrekta. Det är den direkta kopplingen till de verkliga intressenternas behov som måste bli starkare, med en tydligare idé för att underlätta kommunikation mellan intressenter och kravingenjörer.
/Staffan Melin, Require AB