Kravspecifikationer i IT

Øh - ja, det ved jeg da. Men med mindre du har et mere konkret spørgsmål til processen, vil jeg foreslå, at du slår det op på nettet eller biblioteket. Det er trods alt noget, der er skrevet mange store bøger om hvordan man gør, så det vil helt klart føre for vidt at gennemgå alt her. :) Ikke mindst siden det afhænger meget af hvilken type system der er tale om - og især af usikkerhedsgraden. Der er derfor ikke ét endegyldigt svar.

Det du skal være opmærksom på er, at arbejdet med kravsspecifikationens vigtigste funktion er at skabe en gensidig forståelse med kunden om, hvad det nye systems spændvidde og den proces der vil ligge bag dets tilblivelse. I.e. udviklerne skal forstå, hvad det er kunden vil opnå ved systemet - så de har en chance for at vurdere hvilke features er essensielle etc. Og kunden skal forstå hvad dennes rolle i processen er. Til slut skulle man så gerne have en fælles (ens) forventning til det endelige produkts skal kunne. (Det er i hvert fald én skole indenfor det felt. ;))

I den optimale situation stemmer dette så overens med hvad der står i kontrakten - men det er langt fra altid hverken tilfældet eller ønskværdigt.

mange tak for svaret :)

det jeg er kommet frem til er at bruge leavitts modellen og kvalitetstrekanten ? men ved ikke om det er tilstrækkeligt ?

Nu ved jeg ikke hvad kvalitetstrekanten er - men jeg tror, du er har brug for mere substantielle elementer en Leavitt - som jeg iøvrig kun er overfladisk kendskab til. Men som jeg har forstået det, så handler det meget om de organisatoriske konsekvenser af f.eks. indførslen af mere it? Det du skal afdække er kundens behov.

Jeg havde tænkte mere på noget i retningen af rige billeder (tåbelig oversættelse) og use cases .

Siden kunden sjældent har særlige kompetencer indenfor området, afslutter man ofte med to lister med de hhv. funktionelle og ikke-funktionelle krav - abstrakte beskrivelser af hvad produktet forventes at kunne. Eller noget andet som lægmand kan forstå.