[Conny Westh]

Det är viktigt att parterna är noga med att specificera allt som kravställaren vill ha och se till att man har ett bra avtal annars skiter det sig ganska säkert.

I det här fallet är det två problem, en helt oerfaren kravställare och en hyfsat oerfaren (dvs billig) utvecklare, det är ingen bra kombination. Min farhåga är desutom att de varken har avtal eller kravspecifikation i skriftlig form, då är det som upplagt för problem.

Men det är viktigt att kravställaren ska ställa krav utifrån hur det ska fungera i sin verksamhet, inte tekniska krav, för det har beställaren/kravställaren oftast inte tillräckliga kunskper för. Till detta hör att specificera lämpliga testfall så utvecklaren kan testa att dessa testfall fungerar innan denne överlämnar sin leverans.

Allt som kravställaren "kommer på" i efterhand ska beställaren betala utöver fastpriset, det är inte utvecklarens ansvar att stå för den kostnaden.

Börja alltid med att specificera systemets ansvarsområde så du begränsar omfånget, det är lätta tt ställa krav så systemet blir gigantiskt och därmed dyrare än nödvändigt, bättre är att bygga små system som snabbare kommer i produktion.

Definiera vilka olika roller som ska använda systemet, det är helt avgörande för hur man bygger upp strukturen i systemet, exempelvis ska varje externt system som kommunicerar med systemet ha egna roller definierade. Givetvis ska vanliga användare och administratörer ha olika roller m.m.

Kravspecen ska vara specificerad så att kravet är fullständigt beskrivet med text och förväntat resultat gärna i punktform eller med s.k användningsfall (som oftast är helt otekniska beskrivningar av hur rutinen ska fungera i verksamheten). På samma sätt ska testfall beskrivas medinmatningsvärden och förväntat resultat.

Det går alltså INTE att skriva som krav att: "Systemet ska fungera som systemet XYZ", då har man inte specificrat hur det ska fungera utan givit en extern referens till ett system som utvecklaren inte vet hur det fungerar. Det är ett mycket dåligt sätt att beskriva ett krav på.

Kravspecen måste också innehålla en konceptuell informationsmodell/datamodell, vilka begrepp som används i verksamheten och hur de relaterra till varandra.

Ett första steg är att skriva upp alla krav kravställaren har på systemet, sen kan man lämpligen göra en WBS (Work Breakdown Structure) för att bryta ner kraven till de minsta beståndsdelar där utvecklaren "vet" vad som behöver göras. En sån WBS brukar vara mycket matnyttig för att upptäcka saker man missat att ta hänsyn till i sitt projekt. Men detta ska göras INNAN man börjar med projektet, det är en del av förstudien/kravarbetet. När man har en komplett WBS brukar det vara mycket enklare att tids-/resursestimera projektet.

Skilj även på Funktionella krav (Verksamhetskrav) och Icke Funktionella krav (Tekniska krav och allt annat som inte är rena verksamhetskrav).

Sammanfattningsvis kan man anvönda följande mall för att komma igång med sina kravdefinitioner:


PRIMITIV MALL FÖR KRAVSPECIFIKATION:

Icke funktionella krav:
- Ekonomiska ramar
- Tidsmässiga Ramar
- Juridiska krav (Lagar som PUL, Avtal m.m.)
- Tekniska krav (Utvecklingsmiljö, operativsystem, programspråk, ramverk, protokoll m.m.)
- Effektmål i verksamheten (vad har du för mål med systemet i din verksamhet, (hör egentligen till förstudien)

Funktionella krav (Verksamhetskrav):

Användningsfall/Userstories:

Krav 1: ...
Krav 2: ...
.
.
.


Testfall:

Testfall 1: ...
- Input:
- Förväntad output:

Testfall 2: ...
- Input:
- Förväntad output:

Testfall 3: ...
- Input:
- Förväntad output:

Testfall 4: ...
- Input:
- Förväntad output:

Testfall 5: ...
- Input:
- Förväntad output: