Granskning av SOA krav

Det finns undersökningar som visar att så mycket som ca 50% av felen härrör från kraven. Dvs om vi kan hitta felen redan vid kravarbetet så kan vi arbeta mycket mer effektivt. Dessutom så är det mycket billigare att hitta ett fel så tidigt som möjligt.

 

Ett fel som hittas under kravgranskning tar mycket mindre resurser i anspråk att rätta, kanske endast en minut, än ett fel som hittas i drift som kan ta flera dagars arbete i anspråk. Och med tanke på alla buggar som hittas sent och som kostar mycket att rätta är det konstigt att man inte lägger mer tid på granskning. Fast det är förstås svårt att bevisa att det kommer att vara lönsamt med ordentlig granskning, just detta projekt kommer förstås inte att ha problem med kraven. Och kostnaden för att genomföra granskningsarbetet är lätt att peka på, men vinsterna är mycket svårare att se. Men granskning är mycket effektivt och borde genomföras i alla projekt.

 

Varför görs det då inte mer?

En förklaring är som tidigare nämnts att projektledningen och den som beställt utvecklinen inte är säker på granskningens förträfflighet. En annan anledning är att det är svårare att göra bra från början än att sätta sig med ett program och klicka och leta fel. Ytterligare en förklaring är att tidsbrist också slår till mot testgruppen. När trycket ökar börjar även den mest nitiske granskare att tvingas att fokusera på att testa leveransen som nyss kommit istället för att granska kraven för en framtida version av systemet.

Anledningar till att man ska arbeta med granskning är bland andra:

  • Upptäck felen tidigt

Genom att granska kraven kan man redan på skrivbordsstadiet upptäcka många fel. Och testare är de bästa granskarna. Testare är kritiska, vana att granska krav, har ofta stor kunskap om systemet. Och en erfaren testare funderar instinktivt på hur kravet ska testas i testfall och testdata.

  • Ta bort onödiga krav

Granskning av testfall inte bara upptäcker fel tidigt, det visar också då och då att krav som ställs inte är viktiga. Det man ville lösa med kravet kanske går att lösa med en befintlig funktion i systemet.

  • Informationsglapp kan minskas

Då flera delprojekt ska leverera fram en lösning är det stor risk för informationsglapp. Det är svårt att se till att information hela tiden delges alla. Och när trycket börjar öka börjar projekten fokusera mer och mer på sin leverans och har inte tid att prata med övriga projekt. Då är risken alltid stor att man mot slutet ser att leveranserna som är beroende av varandra inte överensstämmer helt. Exempel kan vara:
Information om parametrar som webbgränssnittet behöver har inte nått fram till webbtjänstprojektet som därför behöver lägga mer tid på att utveckla, eller kanske tom göra om vissa funktioner.
Det visar sig att det saknas hela funktioner eftersom kraven i det ena projektet fortsatt att utvecklas utan att den information nått fram till det andra projektet.

För att undvika informationsglapp är det förstås viktigt att de som arbetar med kravställningen hela tiden ser till att alla projekt hålls uppdaterade. Det är enkelt att säga men svårare att genomföra i verkligheten. Ofta är ju IT projket under stark tidspress och måste hantera förändrade och utökade krav som gärna ska hinnas med inom samma tid. Här hjälper dock inte en master testplan, men genom att testgruppen har kontroll över flera projekt är det möjligt att man kan se där glapp finns och peka på detta för projektledningen. Detta pekar på att det ofta kan vara bra att låta testpersoner vara med och granska kraven. De kan ofta ha en bra överblick och även kritiskt kunna granska hur hållbara kraven är.