Kravspesifikasjon

Når listen over små og store behov sammen med en prioritering er klar, kan dere skrive en punktvis kravspesifikasjon som er bestillingen deres. Kravspesifikasjonen fokuserer på hvordan nettstedet skal virke - både for de ansatte som skal vedlikeholde det og de besøkende. Designet spesifiserer hvordan nettstedet skal se ut. 

​

Publiseringssystemer og andre tilliggende systemer dere velger vil ha mye standardfunksjonalitet, men alt kan modifiseres. Tenk kost/nytte. Oppgaver dere skal gjøre ofte, bør fungere så automatisk som mulig. Å legge til et nytt produkt bør gå så automatisk som mulig, men sjelden brukte funksjoner, for eksempel lage runde portrettbilder, kan løses manuelt.

​

Kravspesifikasjonen kan ikke bli for lang og detaljert. Den skal gi viktige føring for å sikre at man er enige og så spesifisere hvordan viktige funksjoner må virke.

​

Se på den nedlastbare Eksempel på kravspesifikasjon.docx for å dette arbeidet.

​

Nå kan dere selv gjøre eller få gjort et grovdesign av en designer. Avklar tidlig hvor såkalt “responsiv” nettsiden skal være.

​

Det koster litt å lage en nettside som er helt responsiv - det vil si at siden tilpasser seg bredden på alle typer skjermer og størrelser på nettleservinduer på en stor skjerm. 

Begynn med hvordan siden skal se ut på en PC-skjerm (fks 1000 pixler bred) Den vil trolig fungere også godt på nettbrett.

Så må alle elementer stables for å fungere på en mobil (Små iphoner er 320 px brede, mens større mobiler kan tegnes i 480 px bredde). 

Hvis dere har tid: Vurderer hva er viktigere på mobil enn på PC. Du fyller ikke ut lange skjema på mobil. Løft opp kontaktinfo høyere på siden i stedet.

Hvis dere så vil ha en nettside som skal skalere fritt mellom disse to ytterpunktene, kan det være enklere å få til dette underveis i utviklingen i stedet for å tegne X antall mellomtrinn. 

​

Noen designere er tilhenger av nettsider sider som fungerer i full bredde på en stor PC-skjerm (opp til 1900 pixler). Det kan være fint, men det stiller høye nye og høye krav til design og bildene du skal bruke.

 

 

Tidsrammer og forsinkelser

​

Tidsramme:
I kontrakten dere signerer ligger spesifikasjonen sammen med en tidsramme. Og her betyr dessverre egentlig tidsramme “tidsplan dersom alt går nesten perfekt”. Det kan skje, men fordi vi lever i en småkaotisk verden: Forbered dere på endringer og utsettelser underveis. Utsettelser kan ha to hovedforklaringer:

​

1) Endrede krav:
Man kan aldri planlegge for alt - hvert prosjekt er litt forskjellig og dere har ikke gjort dette prosjektet en gang før. Legg inn en tidsbuffer og når - ikke om - det blir forsinkelser, kommuniser dem ut i organisasjonen med en gang og forklar at slik blir det dessverre veldig ofte.
 
Akkurat nå sier dere kanskje “vi har en deadline vi bare MÅ holde”. 

Ok, greit. Da må dere planlegge deretter og ta høyde for at det kan komme forsinkelser uten at det dermed velter alt. 

​

En mulighet er å lage en A og en B-liste, så gjøre det som står på A-listen helt lanseringsklart og så begynne med oppgaver fra B-listen. Stikker dere fingeren i jorda, er det mye man kan leve uten eller gjennom å sende brukerne til gamle undersider i noen uker.

​

2) Forsinkelser hos utviklingsselskapet:
Dette kan skje og ha sine forklaringer. Noe må godtas. Man kan stå på sitt og presse utviklingsselskapet hardt. Men et eller annet sted går det en grense.  Pass på at dere opprettholder en god tone. For dere skal trolig leve med utviklingsselskapet gjennom mange år og da er det viktig å skape et verdifullt samarbeid. Tilspisser det seg i en diskusjon, kan du som kunde presse frem en seier her og nå. Men det er ikke alltid lurt. I det lange løp kan slikt skape vondt blod og gjøre at utviklere blir mindre fleksible, hardere på å føre timer og mindre villige til å vri hodene for å skape gode løsninger.