Helhetsåtagande

Skrivet 2016-05-26

Konsten att bygga rätt system genom att undvika missförstånd

Hur kan kravförståelsen öka, genom att konkreta exempel används som specifikation.

traditional_way.png

Många it-projekt använder en variant av viskleken för att förmedla krav till utvecklarna. Kravanalytikerna diskuterar med verksamheten, och skriver kravdokument. Testarna läser och tolkar kraven, och skriver testdokument. Utvecklarna, till sist, läser och tolkar krav- och testdokument, och skriver den kod som blir till ett system.

Det här sättet att arbeta är vanligt (även om jag här kanske målar upp en lite överdriven nidbild), och har ett par stora problem. Ett problem är följande. Eftersom kommunikationen sker via dokument, är det stor risk att förståelse försvinner i varje led. Ett annat problem är att det inte dröjer länge förrän kravdokumenten och testdokumenten börjar divergera från koden. Detta gör att ju längre tiden går, desto mindre kan man lita på att kravdokumenten beskriver vad systemet faktiskt gör.

 correct_way.png 

Men tänk om verksamhet, krav, test och utveckling tillsammans skulle diskutera kraven! Då skulle kravförståelsen öka, hos utvecklarna, men ofta även hos användarna! Om man dessutom jobbar med konkreta exempel för att beskriva kraven, så ökar kravförståelsen ännu mer.

De konkreta exemplen i sin tur kommer att fungera som utmärkta klardefinitioner, eller acceptanstestkriterier.

Genom att dokumentera de konkreta exemplen på ett strukturerat sätt, kan dessa användas som underlag för automatiska tester av systemet, med verktyg som exempelvis SpecFlow. När nu de gemensamt framtagna exemplen används för att testa koden, kommer man till ett läge där koden alltid stämmer överens med exemplen. Det går alltså alltid att lita på att exemplen ger en korrekt beskrivning av systemet! Och tack vare de automatiska testerna kommer koden kunna hållas i bra skick och bli mer förvaltningsbar.

Fördelarna med exempelbaserad kravspecifikation, kombinerat med automatiska tester, kan sammanfattas så här:

  • Ökad kravförståelse
  • Acceptanstestkriterier
  • Levande dokumentation
  • Förvaltningsbar kod.

 

Läs ett annat blogginlägg i ämnet:
Vem ska man tro på? 

Ladda ner vårat whitepaper:
Whitepaper om BDD

Vill ni veta mer? Klicka på knappen nedan:

Kontakta mig - Jag vill veta mer