Dokumentation & validering

Det som ska göras under validerings aktiviteten är att läsa dokumentet noga, hålla intervjuer använda sig av checklistor, prototyper skriva scenarier och användningsfall. Nuseibeh och Easterbrook (2000) förklarar att validera kraven kan vara en svår process eftersom olika intressenter har motsägande mål med utvecklingen vilket kan resultera i konflikter.

Lösningsarkitekt 2 förklarar att på Ninetech så har de en egen mall för kravspecifikation där kraven dokumenteras. Han anser att den är väldigt simple och lätt förståeligt då det bara är lite tabeller där man uppmanas att gruppera kraven i först och främst två sektioner funktionella och icke-funktionella krav. Därefter ska det ytterligare grupperas på vilken kategori kravet hör hemma i t.ex. användarvänlighet, affärslogik, det kanske ska vara nån typ av transaktions spårning, man sätter in det i logiska sektioner för att sedan avsluta med att använda sig av MoSCoW metoden för att rangordna och även sätta ett nummer på alla krav. MoSCoW är en prioriterings teknik som är en förkortning på de engelska orden, Must, Should, Could och Won’t, på svenska översätts de till Måste, Borde, Kunde samt Inte (Eriksson 2008).

Lösningsarkitekt 1 tycker att i de bästa världar så dokumenteras kraven i en kravspecifikation med tillhörande testfall, för att verifiera de så har de manuella testprotokoll där de går igenom att kraven är uppfyllda, alternativ om man inte har gjort en sån översättning i testfall under kravanalysen. Då tar man fram acceptanstest eller testfall under senare fas som då kunden går igenom för att verifiera efter att vi också har gjort det och i vissa fall gör kunden egna testfall. Eriksson (2008) anser att kvalitetssäkring är en återkommande aktivitet som sker genom hela utvecklingen och inte något som ska göras i slutet av utvecklingen.

Lösningsarkitekt 2 anger att vid dokumentation och validering av krav så är de viktigaste rollerna kravinsamlaren från Ninetech först och främst, sen är det lösningsarkitekt, strateg samt så bollar de den sedan med kunden. Men han skulle säga att de tar fram dokumentet och kommer fram med ett förslag och så sen så skickar de det till kunden eller sätter sig med kunden går igenom den, eventuellt få lite synpunkter och så går man hem fixar det och sen är det färdigt. Granskning är en effektiv metod att använda sig av kvalitetssäkring av kraven (Eriksson 2008). Granskningsprocessen går ut på att en grupp bestående av olika roller som

38 tillsammans går igenom kravdokumenten för att hitta fel och reda ut eventuella oklarheter. Rollerna i gruppen kan bestå av kravställaren, testaren, systemutvecklare/IT-arkitekt,

användarrepresentant samt projektledare eller systemägare (Eriksson 2008). Kunden är ju med i dokumentationen i och med att man måste säkerställa alla krav med kunden att det här kravet är rimligt och korrekt. Men det gör man mer i kravanalysen, så man ser det från kravanalysen att denna analysen spottar ur sig korrekta krav liksom. Om man då ser det lite stelbent nästa stege efter analysen som man har ju fått en hel hög med krav som är korrekta och analysera de så att säga och bara få in det i dokumentet och sätta nummer på de och liksom sätta rätt

prioritering.

Det gör nog oftast Ninetech själva och sen tar det med kunden när det är gjort.

Strateg Hos Ninetech är de roller vi redan pratat om, hos kunden vi gör väl oftast så att vi helt enkelt bara dumpar det på den kontakt personen som är hos kunden och så får faktiskt de bemanna upp på det sätt de själva tycker är lämpligt. Däremot så tycker jag att det ör de personer som har varit med hos kunden och jobbat fram kravbilden som också ska vara med och validera den

Lösningsarkitekt 1 förklarar att dokumentation och validering är två olika saker vid frågan om vilka roller som bör vara med vid dokumentation och validering av krav. För dokumentation av krav så anser han att det oftast är en lösningsarkitekt eller en verksamhetskonsult samt att en testare eller testledare bör vara med redan då för att skriva testfallen. För validering så anser han att det nån form av testare och kunden som genomför de.

Strategen anser att bristen med dokumentering av kraven är att det är ju svårt o samla in det dokumenterade krav. Strategen förklarar vidare att om man kan jobba lite mer enhetligt och lite mer formellt med kravdelen, så skulle det underlätta för all involverade. Han anser att det är väldigt svårt för utvecklarna framförallt och även lösningsarkitekter att kraven som kommer in är på så otroligt olika nivå. Det är olika nivå på kraven som går in i projekten så det kan vara en och samma utvecklare som övertydligt jobbar med tre olika projekt och tre helt olika förutsättningar liksom och lyckas med och göra det som de ska göra. En större enhetlighet tror jag liksom skulle gynna oss och brista blir ju då att men är det en person som inte är lika duktig på att definiera, dokumentera samt uttrycka krav då blir det sämre kvalité på de och då blir det bristen

Lösningsarkitekt 1 anser att det är jättevanligt att man misstolkar varann eller att man översätter i text till nånting som inte riktigt så man inte får ner det i text till det som man egentligen hade tänkt. Det är därför det är så viktig att man återkopplar och man går igenom kraven så att man menar att båda har förstått vad den andra menade och att de som är nedskrivet på bästa sätt återspeglar de som man menar

Genom att man stämmer av de ordentligt. Skriver ner de läst igenom de. Processen är komplext på så sätt att man försöker beskriva ett krav på flera sätt, så ingenting missas där.

Funktionella krav

Funktionella krav handlar om något som systemet kan utföra (Dennis, Wixom & Roth 2010). Pohl och Rupp (2011) anser att funktionella krav handlar om det som behövs för att systemet ska fungera på ett speciellt sätt, alltså vad systemet skall kunna göra. Strategen anser att det viktigaste med funktionella krav är att de dokumenteras, samt att det är ännu bättre om de dokumenteras i det sammanhang de ska användas. Alltså stuket som user-stories får, det behöver dock inte vara dokumenterad via user storie, men det är bra att veta för vem man gör kravet och vad det är som är viktigt på det. De funktionella kraven ska beskriva tjänster som systemet ska erbjuda, hur systemet ska reagera på indata samt hur systemet ska bete sig under vissa situationer (Sommerville 2009).

39 Sommerville (1998) beskriver kravdokumentet som ett dokument som innehåller det

utvecklarna ska implementera samt att kravdokumentet ska skrivas på en begriplig nivå för att vara som stöd för alla verksamhetsaktörer. Lösningsarkitekt 1 förklarar att funktionella krav ska dokumenteras i kravspecifikationen i ett eget kapitel, nedbrutet på skall krav, bör krav osv, gärna med exempel om det är tillämpbart.

Testaren klarlägger att om det är en större lösning med kanske fler än 20 krav eller så då underlättar det ju ganska mycket om man grupperar kraven även funktionellt, mest

grundläggande är om man ska ha ett användargränssnitt och ett admingränssnitt. Då är de två indelningar. Sommerville (1998) anser därmed att kravdokumentet kan vara mer begriplig om det finns diagram modellerade som överensstämmer med dokumentets innehåll.

Brister vid dokumentation av funktionella krav är jättevanligt, t.ex. att man missar saker är det vanligaste enligt lösningsarkitekt 1. Att man inte uttrycker sig tillräckligt bra så att alla

intressenter riktigt förstår vad man menar snarare att de olika intressenterna tolkar det som olika saker är jättevanligt. Därför är det superviktig att man har en dialog kring det och inte bara läser/löser. Annars uppkommer det i slutet av projektet att det var inte alls det som kunden ville ha.

Sommerville och Sawyer (2004) förklarar att kvalitetssäkring handlar om att säkerställa sig att kraven följer de kvalitetsstandard som är satt. De anser att kraven som är dokumenterade måste valideras för att hitta krav som missats, eventuella konflikter mellan krav och/eller otydliga krav Testaren anser att dokumentationen av kraven kan bli mycket bättre eftersom hon skulle vilja lita på kravdokumentet som hon får i handen, om det nu inte är meningen att hon ska vara med under kravhanteringen. Testaren förklarar att de brister som förekommer vid dokumentation av funktionella krav kan undvikas genom att ha folk som har rollen ”krav”, man kanske inte behöver jobba enbart med krav men man behöver ha det på folk att de jobbar med krav.

Enligt lösningsarkitekt 2 så är de vanligt förkommande med brister vid dokumentation av funktionella samt icke-funktionella krav men att det är väldigt lätt att missa nåt område särskilt vid dokumentation av icke-funktionella krav. Sommerville och Sawyer (2004) anser därmed att när kvalitetssäkring genomförs så är det rekommenderat att alla intressenter som var med vid insamling av krav att vara med för att eventuellt förtydliga oklarheter.

Icke-funktionella krav

Icke-funktionella krav handlar om hur systemet ska fungera samt vilka valmöjligheter det finns till att använda systemet (Dennis, Wixom & Roth 2010). Samtliga respondenter anser att de icke-funktionella kraven ska dokumenteras på samma sätt som de funktionella kraven samt att de mest vanliga bristerna med icke-funktionella kraven är att de oftast är otydligt

definierade och att de som skriver de oftast tar lite för lätt på de.

Lösningsarkitekt 1 förklarar att de icke-funktionella kraven gärna kan dokumenteras med exempel samt att det är ännu viktigare med exempel eller mätbara mått om det är möjligt så det inte är nåt flummigt som man kan tolka hur man vill, eller att olika personer tolkar på olika sätt. Chung och Nixon (2000) anser att icke-funktionella krav kan vara hur

användargränssnittet ska se ut eller hur många användare som ska använda systemet. Testaren anser att de icke-funktionella kraven behöver ofta specificeras mycket mer än de funktionella kraven, icke-funktionella krav kan handla om lite prestanda eller att lösningen ska fungera på både mobila plattformar och pc osv. Testaren anser bristerna kan undvikas genom att man blir mer medveten om att en lösning inte bara är ett gäng funktioner utan att en lösning ska vara svaret på ett problem som kunden har.