Verifiering och validering är två begrepp med olika betydelse.

Verifiering är en aktivitet som ofta av naturliga skäl blir koncentrerad till mitten eller mot slutet av ett projekt, vilket inte är helt gynnsamt. Det som är avgörande för en lyckad verifiering är att börja verifieringsförberedelserna med full kraft redan från projektstart.

Det finns en MIL-standard, MIL-STD-1521B som definierar processer som kan användas för att erhålla en lyckad verifiering. Processen behöver ofta anpassas i en åtagandebeskrivning eller Statement of Work (SOW) som är en del av kontraktet.

Nedan följer en populärbeskrivning om hur man kan nyttja MIL-standarden för att kunna erhålla en lyckad verifiering i ett projekt.

Vid projektstart diskuterar kunden och leverantören igenom samtliga krav i specifikationerna och redogör för sina respektive förväntningar på realiseringen av varje krav. Syftet är ett ensa, dvs kommer överens om en gemensam förväntning om vad kravet innebär. Denna ensade förväntan protokollförs för att nyttjas i PDR och CDR enligt nedan.

I samma process uppstår även per automatik kravtolkningsdiskussioner vilket ofta leder till förtydligande av otydliga krav vilket är mycket positivt ur ett verifieringsperspektiv. Som exempel finns det ett par sk funktionsverb som förekommer i specifikationerna och som oftast innebär svåra utmaningar vid verifieringen. Här är ett litet urval:

• Stöjda eller “ha  stöd för”- vad innebär detta mer konkret, vad är det som ska uppfyllas?
• “Hantera” – Vad innebär det konkret, vad är det som ska uppfyllas?
• “Övervaka” – Vad ska övervakas och hur ska det övervakas? Vad ska uppnås?

Om det är otydligt vid SRR är detta ett bra tillfälle att tillsammans med leverantören skriva om kravet så att kravet blir tydligt vad som ska uppnås och att det därmed gå att verifiera när det blir dags.

Denna granskning kallas System Requirements Review (SRR).

Granskningen i SRR är helt avgörande för en lyckad verifiering eftersom det är inför och under konstruktionsfasen som det går att påverka den realisering/konstruktion som leverantören ännu inte har gjort.

Granskningen protokollförs och avsikten är att ensa förväntningarna, annars skapas garanterat problem vid verifieringen.

Efter att SRR är genomförd börjar konstruktionsfasen. Leverantören kallar då till kravrealiseringsmöten där leverantören i text inför mötet redovisar hur respektive krav avses realiseras/konstrueras.

Kunden får under dessa möten uppgiften att ställa frågor kopplade till kravställningen för att säkerställa att kravet blir uppfyllt och att förväntningarna enligt överenskommelsen från SRR överenstämmer med den beskrivna konstruktionen.

Utöver kravrealiseringen diskuteras även verifieringsförutsättningen för respektive krav, exempelvis i vilken testmiljö ska kravet verifieras , behövs något särskilt testverktyg eller finns det andra förutsättningar?

Tanken med att starta kravrealiseringsmöten direkt efter SRR är att kunna fördela kraven i flera kravrealiseringsmöten samt att man startar med de krav som leverantören avser att börja realisera i sin konstruktion. Är det många krav blir det givetvis också många kravrealiseringsmöten.

Ur ett verifieringsperspektiv är dessa möten viktiga eftersom leverantören redovisar sin tilltänkta konstruktion för att uppfylla respektive krav. Inför PDR skapas alltså förutsättningarna för att erhålla OK i verifieringen.

Kundens utmaning under dessa möten är att ställa rätt frågor så att leverantörens kravrealiseringsbeskrivning blir heltäckande mot både krav och förväntningar. 

Kravrealiseringsbeskrivningen och verifieringsförutsättningarna protokollförs. När ett krav har fått godkänt i protokollet kan leverantörens börjar konstruera.

Avsikten är att bli överens under dessa kravrealiseringsmöten. Det är därför en förutsättning att de som deltar på dessa möten har beslutsmandat att fatta beslut eftersom brist på beslut eller uppskjutet beslut ofta innebär att leverantören inte kan starta realiseringen av de kraven som saknar beslut, vilket nästan alltid leder till förseningar och fördyringar.

Denna granskning kallas Preliminary Design Review (PDR) och blir en enkel avstämning vid ett visst datum att man hunnit gå igenom ca 80% av alla krav.

De sista 20% av kraven gås igenom inför Critical Design Review (CDR) som är ett datum då kravrealiseringen för alla krav ska vara granskade och överenskomna. De sista 20% brukar vara de svåraste kraven att komma överens om och här gäller det att ha kvar orken och fokus för blir överens så att verifieringen blir lyckad.

Mellan PDR och CDR kan det också hända att PDR-kraven måste gås igenom, för givetvis kan realiseringen ändras då man blivit klokare under vägen.

Efter CDR ska alla frågor vara besvarade. Det som är kvar är kvarvarande produktion och kvarvarande verifiering. Därmed skapas förutsättningar att CDR också blir en avstämning att leverantören kan leverera enligt tidplan.

Verifieringen kan faktiskt starta innan PDR passeras , bara parterna är överens om kravrealiseringsbeskrivningarna och verifieringsförutsättningarna för de krav som ska verifieras.

Normalt är dock att verifieringsaktiviteterna startar ganska sent efter PDR eftersom leverantören måste blir klar. Efter att CDR är klart brukar verifieringsaktiviteterna peaka då projektet är på upploppet och alla krav som är kvar ska testas med målet att erhålla OK.

Ovanstående process kan uppfattas som tidskrävande . Poängen med processen är dels att reda ut alla frågor innan leverantören har gjort sin konstruktion och dels maximera mängden OK (=krav uppfyllt) vid verifieringen. Därmed slipper både leverantören och kunden lägga både tid och pengar på administration, omkonstruktion och omprov som blir konsekvensen när krav erhåller ett NOK (Not OK) i verifieringen.

Följer man processen enligt ovan blir kunden tryggare innan verifieringen med att man får det man betalar för innan det är för sent, dvs efter att konstruktionen är gjord, medan leverantören blir tryggare med att den tilltänkta konstruktionen kommer uppfylla kraven och därigenom finns förutsättningar för att maximera mängden OK vid verifieringen.

Att hantera konsekvenser för de krav som inte blir OK pga skillnad i parternas kravtolkning och förväntning är alltid kostsamt efter att kravet har verifierats till ett NOK jämfört med att ta diskussionen innan eller under konstruktionsfasen och därmed öka chansen att erhålla ett OK.

Härmed sagt att verifieringsarbetet i ett projektet startar när projektet startar.

I verifieringsarbetet hanteras ett antal begrepp som beskriver status för ett krav:

• OK = kravet är godkänt
• NOK = kravet är inte godkänt
• NOT = kravet är inte testat
• !OK = kravet har annan status än OK