Krav – det kanske mest mystiska som finns

Få saker inom branschen är så debatterade och mystifierade såsom Krav. Några påstår att de ska vara heltäckande, andra bara visa vägen och en tredje inte ens bryr sig om att skriva dem. Det är bara att vänja sig att du kommer inte få se några heltäckande, perfekta krav. När du väl har kommit till insikt med detta så har du kommit en bra bit på vägen. Krav är som allt annat väldigt tolkningsbart och det bästa du kan ha är ett pragmatiskt synsätt när det gäller dem. Jag ser krav som informationsbärare. Är de välskrivna såsom användningsfall eller med en prioritering och kvantifiering så försöker jag läsa det som inte står. Ifrågasättandet är nyckeln för ett bra kvalitetsarbete. Låt dig inte styras av vad någon har tyckt och tänkt från början, för det är en sak. En annan sak är hur det verkligen blir.

Se upp med krav såsom bygger på följande andemeningar eller beståndsdelar:

-Det skall se snyggt och proffsigt ut. (Tyckande)

-Det skall vara snabbt. (Tyckande och vad är snabbt, under vilka omständigheter?)

-Det skall fungera som tidigare. (Ofta finns det inget som beskriver det som var tidigare)

-Utan sammanhang. (Sammanhanget betyder allt)

-Saknar prioritet.

En metod som jag använt mig många gånger är en review teknik som jag kallar WWH – What, When and How. Allt beror nämligen på sammanhanget. Ett krav behöver en egen värld för att leva. Den världen är sammanhanget. Vad är det som ska göras (What), i vilken kedja av händelser, användningsfall och tid (When) och till sist hur ska det göras (How).

Den här metoden har räddat många testprojekt för mig. Du tar helt enkelt reda på världen som kravet eller kraven lever i. Testbarheten i ett krav beror på om någon har tänkt på att det ska kunna mätas eller tolkas på ett för projektet och slutkunden bra sätt.

En sak som jag har noterat är att ofta dör krav med projektet och inte produkten. I de fallen har man missat en av de viktigaste sakerna för underhåll och vidareutveckling. Krav ska beskriva produkten och skall uppdateras under hela livscykeln. Det samma gäller de testfall som utgör regressionsbasen.

Användningsfall är ett bra sätt att få med sammanhanget, då man oftast kan få det beskrivet rent funktionellt och i vilken ordning som något är tänkt att fungera i. Projekt med användningsfall brukar ha en högre kvalitet från utvecklarna då utvecklarna som skall realisera en önskebild (via krav) får mer information om just WWH. Men, tänk även här att det viktigaste är ofta det som inte står. Läs användningsfallet och granska det noga. Gå utanför ramarna när du testar det, så kommer du hitta felen eller förstå hur robust arkitekturen är.

Lycka till!