Förbättra samarbetet via Kravspecifikation genom exempel

2012-05-15 Artikelbanken Kravhantering Läst 16094 gånger

I många organisationer är det förhållandevis vanligt att det finns svårigheter med förståelsen mellan verksamhet och IT om vad som ska utvecklas, varför och för vem. Detta kan leda till att fel system utvecklas eller att det blir en infekterad stämning mellan olika delar av organisationen. Det finns ett flertal nyare metoder för att hantera kravspecifikationer och testarbete som ett sätt att bemöta dessa svårigheter. De delar en gemensam grund av principer som är ganska snarlika och samtliga av dem syftar till att hitta vägar för att överbrygga luckorna mellan krav från verksamheten och den funktionalitet som utvecklas.

Några kända metoder/benämningar är:

  • Agil acceptanstestning
  • Exempeldriven utveckling
  • Behovsdriven utveckling
  • Smarta scenarier
  • Kravspecifikation genom exempel

 

Det faktum att det finns ett flertal olika metoder/benämningar för snarlika hanteringar av problematiken tyder på att det händer väldigt mycket inom området för tillfället. Oavsett om vi väljer att kalla det för Behovsdriven utveckling, Agil acceptanstestning eller Kravspecifikation genom exempel så vill vi ha samma resultat - en delad förståelse över vad som skall utvecklas, varför och för vem.

Denna artikel behandlar metoden Kravspecifikation genom exempel. En utav metodens fördelar är att man kopplar utvecklingsprocessen mot kravarbetet. På så vis får man med sig verksamhetsidan i utvecklingsarbetet. Detta medför att man lättare kan överbrygga kommunikationsproblematik och tvinga fram en gemensam begreppsvärld att samarbeta kring mellan organisationsdelarna. Syftet med utvecklingsarbetet är oftast att lösa ett problem eller uppfylla ett behov. Många utvecklingsteam förväntar sig att en produktägare eller kund skall besluta om lösningsdetaljer innan implementationen tar vid. Det är ofta redan här problemen med att utveckla rätt saker börjar. Genom att förvänta sig att verksamhetsidan levererar en lista på krav, användningsfall, användningsscenarier och annan kravdokumentation har utvecklingsteamet i princip bett verksamhetsidan att skapa lösningen åt dem.

Artikeln fungerar som en handledning igenom att antal nyckelaktiviteter som vi väljer att illustrera nedan med hjälp av våra tankemodeller ”tratten och snurran”.

Bryt ut omfattningen från verksamhetsmålen

Om verksamheten definierar färdiga lösningsförslag med fokus på vilka system som ska påverkas och på vilket sätt, så utnyttjar man inte kunskapen som finns i utvecklingsteamet. Detta innebär att utvecklingsteamet i bästa fall levererar mjukvara som uppfyller ”kraven” men inte uppfyller vad kunden verkligen vill ha eller behöver.

Utvecklingsteamet måste se bortom lösningsförslag och bryta ut omfattningen från det faktiska verksamhetsmålet. Detta bör man göra tillsammans med verksamhetsrepresentanter som fokuserar på att kommunicera verksamhetsbehovet och vilket värde de förväntar sig. Detta hjälper alla till att få en gemensam förståelse kring vilka förväntningar man har på varandra. Utvecklingsteamet kan med bakgrund av detta många gånger föreslå en lösning som är billigare, snabbare eller lättare att leverera och underhålla än vad verksamheten hade kunnat tänka ut på egen hand.

Specificera krav tillsammans

Om inte utvecklare och testare är engagerade i kravarbetet måste kraven kommuniceras till teamet efter det att de är ”klara” vilket lätt kan leda till missförstånd. Som en konsekvens av att man inte samarbetar kring kravarbetet behöver verksamheten validera lösningen efter leveransen och teamet måste rätta till felen i efterhand vilket är ett onödigt arbete. Istället för att lita på att verksamheten skall lyckas få specifikationen korrekt borde teamet samarbeta med en verksamhetsrepresentant när man specificerar kraven. Människor med olika bakgrund och med olika idéer använder då sin samlade erfarenhet till att lösa problemen och uppfylla behoven.

När man specificerar krav kan man göra det på många olika sätt. Ett sätt är att specificera krav som användarberättelser. Här följer ett exempel på ett enkelt krav som syftar till en funktion som lägger ihop två heltal och beräknar summan av dessa.

Feature: Calculate
In order to avoid silly calculation mistakes
As a math beginner
I want to be told the sum of two numbers

Här väljer jag att beskriva mina krav på engelska. Varför kommer att framgå längre fram i artikeln. Exemplet är lånat från hemsidan Cucumber.

Ökad förståelse genom användning av exempel

På verksamhetssidan är det vanligt att en verksamhetsanalytiker (”Business Analyst”) arbetar genom ett antal realistiska exempel som kommuniceras gentemot sina kundrepresentanter. Tyvärr översätts sedan dessa till specifikationer som beskriver vad som skall utvecklas. Denna typ av krav, som saknar en indikation av ”varför? och ”för vem?” är väldigt svåra att ta till sig och fungerar dåligt som underlag för utveckling och test.

En annan utmaning är att vardagsspråket är tvetydligt och öppet för tolkning. Detta gör att ett krav som är beskrivet i ett vardagsspråk sällan är helt färdigställt. Utvecklare och testare behöver tolka sådana krav för att kunna producera mjukvara och test script, och människor tolkar förmodligen en del krav olika. Detta blir riktigt problematiskt när någonting verkar uppenbart men det behövs en specifik domänkunskap eller erfarenhet för att förstå allt till fullo. Istället för att lita på att kravspecifikationer skall konkretiseras rätt första gången i programkod så kan man istället göra kraven konkreta genom att använda sig av exempel, tillsammans med verksamhetsrepresentanter.

Börja med att identifiera nyckelexempel, som är typiska representativa exempel för alla viktiga funktioner som krävs för att uppfylla en kravspecifikation. Utvecklare, testare och verksamhetsrepresentanter tar sedan fram tilläggsexempel till dessa nyckelexempel för att illustrera specialfall eller andra problematiska delar av systemet. Detta överbryggar funktionella luckor och säkerställer att samtliga som är involverade i kravarbetet delar en förståelse om vad som behöver levereras, vilket minskar risken för extra arbete på grund av misstolkningar.

 

Om vi går tillbaka till vårt exempel för kravet Calculate och utökar den med en scenariobeskrivning skulle det kunna se ut så här:

Scenario Outline: Add two numbers
 Given I have entered into the calculator
 And I have entered into the calculator
 When I press
 Then the result should be on the screen

 

För att bara validera att resultatet blir summan av de två delarna så kan vi även lägga till exempel som förtydligar vad vi förväntar oss.

Examples:
| input_1 | input_2 | button | output |
| 20 | 30 | add | 50 |
| 2 | 5 | add | 7 |
| 0 | 40 | add | 40 |

 

Om systemet fungerar korrekt för samtliga nyckelexempel så vet vi att det uppfyller kravspecifikationen som vi gemensamt kom överens om. Exemplen definierar även vad mjukvaran behöver göra. De är både målsättning för utveckling såväl som att de fungerar som en objektiv utvärderingskriteria för att stämma av ifall utvecklingen är klar. Om exemplen är lätta att förstå och kommunicera så kan vi ersätta våra krav med dessa.

Att förädla kravspecifikationen

Att ha en öppen dialog kring samarbetet när man tar fram en specifikation bidrar till en delad domänförståelse, men exemplen innefattar ofta en rikare detaljnivå än vad som faktiskt är nödvändig för att kunna illustrera en funktion. Verksamhetsrepresentanterna tänker ofta på systemet utifrån användargränssnittet så de kommer att bidra med exempel som illustrerar hur något bör fungera med utgångspunkt från slutanvändaren som syftar till att uppfylla ett verksamhetsbehov.

Att använda sig av sådana beskrivningar specificerar även hur något skall göras och inte bara vad som skall göras. Man skall försöka undvika ett överskott av detaljer då dessa gör exemplen svårare att kommunicera och förstå. Vi förädlar specifikationerna genom att från nyckelexemplen ta bort onödiga detaljer, och genom förädlingen får vi något väldigt konkret och precist som både utveckling och test lätt kan ta till sig.

Automatiserad kravvalidering

Så fort vi kommer överens om vilka exempel som gäller för specifikationen och vi har förädlat dem så kan vi använda dem vid implementation och validering av produkten. Systemet kommer att bli validerat vid flertalet tillfällen under utvecklingsarbetet för att säkerställa att vi möter målet. Att utföra dessa kontroller manuellt skulle medföra onödiga förseningar och återkopplingen det skulle medföra skulle gå för långsamt. Snabb återkoppling är en primär del av utvecklingsprocessen, så vi behöver skapa en process där valideringen av systemet är billig och effektiv. En uppenbar lösning på detta är att automatisera.

Den typ av automatisering vi önskar är dock annorlunda än den normala automatisering som utförs av utvecklaren eller testaren. Om vi automatiserar valideringen av nyckelexempel genom att använda oss av traditionell programmering, unit-automatiseringsverktyg eller andra typer av automatiseringsverktyg så riskerar vi att introducera problem om saker försvinner i översättningen från verksamhetskraven till teknisk automatisering. Tekniska automatiserade specifikationer kommer att bli otillgängliga för verksamheten på grund utav det tekniska djup som krävs för att förstå dem.

När kraven ändras, vilket de kommer att göra då utvecklarna och testarna behöver ytterligare förklaringar eller förtydliganden, så kommer vi inte ha möjlighet att använda specifikationen som vi precis automatiserat. Vi skulle kunna behålla nyckelexemplen i en mer läsbar form men så snart det existerar mer än en sanning så har vi problem att säkerställa vilken sanning som gäller. Det är därför stora kravdokument aldrig är helt korrekta.

Om man sparar all information som existerar i kravspecifikationen i verktyget när man automatiserar så minskar risken att man börjar misstolka kraven. Det innebär att när man automatiserar valideringen utan att förändra specifikationen, så förändras inte nyckelexemplen utan de förblir i sitt läsbara ursprungskick och är tillgängliga för samtliga involverade intressenter.

 

Exempel:

Jag väljer att använda mig av Cucumber som är ett verktyg som är anpassat för att kunna exekvera kravspecifikationer. Då verktyget kommer att använda sig utav kravet för att exekvera kod-stubbar behöver vi skriva kraven och även senare koden på engelska. Jag kommer inte i den här artikeln gå in på hur man sätter upp miljön och allt annat runt omkring för att få det att fungera, utan här vill jag endast visa på principen.

 

Steg 1: Vi börjar med att ta Funktionen, Scenariot och Exemplet som jag beskrev tidigare i artikeln och matar in dem i anteckningar. Efter det så sparar vi ner dem som calculate.feature.

 

Feature: Calculate
In order to avoid silly calculation mistakes
As a math beginner
I want to be told the sum of two numbers

 

Scenario Outline: Add two numbers
 Given I have entered into the calculator
 And I have entered into the calculator
 When I press
 Then the result should be on the screen

 

Examples:
| input_1 | input_2 | button | output |
| 20 | 30 | add | 50 |
| 2 | 5 | add | 7 |
| 0 | 40 | add | 40 |

 

Steg 2: Beskriv stegen i Ruby kod(Ruby är det programmeringsspråk som Cucumber använder sig utav) och spara ner dem som calculator.steps

require 'calculator'
Before do
[email protected] = Calculator.new
end

After do
end

Given /I have entered (\d+) into the calculator/ do |n|
[email protected] n.to_i
end

When /I press (\w+)/ do |op|
[email protected] = @calc.send op
end

Then /the result should be (.*) on the screen/ do |result|
[email protected] == result.to_f
end

Steg 3: Kör ditt exekverbara krav genom att anropa ditt automatiserade krav genom att i commando prompten köra ”cucumber feature.calculator”.

Steg 4: Ifall det exekverbara kravet går igenom kommer du att få en liknande utskrift som nedan.

 

Feature: Calculate
In order to avoid silly calculation mistakes
As a math beginner
I want to be told the sum of two numbers

 

Scenario Outline: Add two numbers
 Given I have entered into the calculator
 And I have entered into the calculator
 When I press
 Then the result should be on the screen

 

Examples:
| input_1 | input_2 | button | output |
| 20 | 30 | add | 50 |
| 2 | 5 | add | 7 |
| 0 | 40 | add | 40 |

3 scenarios (3 passed)
12 steps (12 passed)
0m0.015s

 

En automatiserad specifikation med exempel blir då en exekverbar kravspecifikation som vi kan använda gentemot utveckling för att kontrollera ifall systemet gör det vi kom överens om. I vårt fall så passerar kravvalideringen ifall summan av ”input_1” och ”input_2” blir resultatet som står under ”output”. Om summan inte stämmer överens med förväntat resultat så har kravvalideringen misslyckats.

Vi kan även använda detta dokument för att få förtydliganden från verksamhetsidan. I de fall vi behöver förändra specifikationen så behöver vi endast göra detta på ett ställe.

För att effektivt underhålla ett mjukvarusystem, behöver vi veta vem som gör vad med den, och varför. I många fall så är enda sättet att ta reda på detta att analysera koden. Koden är ofta det enda vi kan lita på. Det mesta av den skrivna dokumentationen är gammal och den är sällan helt korrekt. Programmeraren blir en källa till kunskap men även en flaskhals vad gäller kunskapsspridningen. Exekverbara specifikationer kan enkelt valideras gentemot systemet för att kontrollera om systemet fortfarande gör vad det skall. När valideringen är ofta förekommande kan vi ha lika stor tillförlit till den exekverbara kravspecifikationen som till själva koden. Genom att kontrollera samtliga specifikationer upptäcker vi snabbt förändringar mellan systemet och specifikationerna. Eftersom specifikationerna är enkla att förstå, kan man även diskutera dessa förändringar med verksamhetsidan och bestämma hur man bäst bör angripa eventuella problem.

Att utveckla ett dokumentationssystem

Man behöver inte stanna vid att få till exekverbara specifikationer som frekvent valideras. Man kan även se till att specifikationerna är organiserade, lätta att hitta, tillgängliga samt konsekventa. Allt eftersom utvecklingsarbetet fortgår ökas domänkunskapen, marknadsmöjligheter uppstår och skapar förändringar i verksamheten. För att få ut det mesta av Kravspecifikation genom exempel bör man uppdatera kravspecifikationerna gentemot dessa förändringar. Genom detta arbete skapar man ett levande dokumentationssystem. Levande dokumentation ersätter samtliga artefakter som utvecklingsteamet behöver för att kunna leverera rätt produkt, men på ett sätt som passar väl samman med ett iterativt arbetsätt.

Levande dokumentation är en pålitlig källa till information om systemets funktionalitet som samtidigt är lättillgänglig. Det är lika tillförlitligt som kod, men lättare att läsa och förstå. Support kan använda det till att förstå vad systemet gör och varför. Utvecklare kan använda det i utveckling, testare kan använda det till testning och kravanalytiker kan använda det som startpunkt när man analyserar påverkan av en beställd förändring av funktionalitet och det ger oss samtidigt regressionstestning gratis.

Sammanfattning

Kravspecifikation genom exempel är ett samarbetssätt för att definiera krav och acceptanstester för mjukvarubaserade produkter, baserat på att man fångar och illusterar krav genom realistiska och konkreta exempel istället för abstrakta. Synsättet är applicerbart i olika agila miljöer men fungerar i synnerhet väl tillsammans med Behovsdriven utveckling.

Kravspecifikation genom exempel syftar till att skapa en enda källa av sanningen, från samtliga perspektiv. När verksamhetsanalytikern arbetar på sina kravdokument, utvecklaren hanterar sina implementationsspecifikationer och testaren hanterar en separat uppsättning av funktionella tester så minskas effektiviteten på mjukvaruleveransen på grund av konstant koordinering och synkronisering kring de olika versionerna av sanningen.

Vi upplever att Kravspecifikation genom exempel minskar återkopplingstider inom mjukvaruprojekt vilket leder till mindre omarbete, högre produktkvalitet och bättre gruppering av aktiviteter för olika roller som är involverade så som Testare, Kravanalytiker och Utvecklare.

Källhänvisningar

Utöver egen erfarenhet och samlad erfarenhet från andra Konsultbolag1 medarbetare vill författaren ange följande källor till artikelns innehåll:

Böcker
Specification by example http://manning.com/adzic/
Bridging
the Communication Gap http://www.acceptancetesting.info/the-book/

Hemsidor
Specification by example http://specificationbyexample.com/
ATDD vs. BDD vs. Specification by example http://janetgregory.blogspot.se/2010/08/atdd-vs-bdd-vs-specification-by-example.html
Cucumber http://cukes.info/
Cucumber Exemplet är baserat på. https://github.com/cucumber/cucumber/blob/master/examples/i18n/en/features/addition.feature
Gojko Adzic egen hemsida http://gojko.net/

Nästa steg

Läs andra relaterade artiklar:
Smarta scenarier - för en bättre IT-beställning

Anmäl dig till en av Konsultbolag1s populära kurser inom kravhantering och test:
Effektiv kravhantering - process, roller, ansvar, aktiviteter, begrepp, praktisk verktyglåda inom kravhantering
Effektiv testmetodik - process, roller, ansvar, aktiviteter, begrepp, praktisk verktyglåda inom test
Kravdesign - tekniker för att fånga, förädla och kommunicera krav

Kunskapsbanken inom kravhantering och test:
KB1online - din kunskapsbank för att bli mer tvåbent inom kravhantering och test avseende både ett helhetsperspektiv och konkreta verktyg i form av aktiviteter, roller, ansvar och mallar.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln