Åpen kravspesifikasjon

Hver eneste gang en organisatorisk enhet skal kjøpe inn programvare så utarbeides det en kravspesifikasjon. Denne blir da, sammen med pris og andre kriterier, lagt til grunn for innkjøp av programvaren. I ettertid, når brukerene ikke er fornøyde så kan leverandøren vise til hva som sto og hva som ikke sto i kravspesifikasjonen.

Det å skrive en fullgod kravspesifikasjon er vanskelig. Det er svært omfattende om man skal sikre at systemet fungerer slik man har tenkt seg. Trøsten er at kravspesifikasjonen man brukte i fjor kan brukes som kladd, og man legger til de punktene man føler at man manglet og retter det som er feil. Det kan for eksempel gå på brukervennlighet, men bør konkretiseres så godt at det ikke kan misforstås. For eksempel ville jeg hatt med at “Nye elementer i brukerens LMS-portefølge skal vises frem med forhåndsvisning på forsiden, lett tilgjengelig.” eller “interoperabilitet mot andre systemer skal ivaretas.” OK, det kan formuleres bedre enn det, men du skjønner hva jeg mener.

Hakket bedre enn at jeg bruker min egen kravspesifikasjon i fra i fjor, er at jeg bruker den, og får se på nabokommunens kravspesifikasjon i tillegg. Dette gjøres jo allerede i mange innkjøpssamarbeid kommuner og fylkeskommuner mellom.

Aller best hadde det vært hvis vi hadde en wiki (eller hva som helst) for kravspesifikasjoner, hvor alle kunne legge inn sine krav, for LMS, kontorpakke, operativsystem, skoleadministrative system, og så videre. Først da kan vi klare å lage en så god kravspesifikasjon leverandørene må jobbe etter at vi før akkurat det vi har tenkt oss.

Det som er ekstra kult med en åpen kravspesifikasjon, er at vi da selv kan bestemme hvordan fremtidens databehandlig skal foregå. Hvordan er ditt drømme-LMS?

Kommunikasjon er nøkkelen til gode løsninger. En dag bare virker alt. Bare trykk på knappen, så vips.

2 thoughts on “Åpen kravspesifikasjon”

  1. Enda bedre er en agil prosess, der man ikke har ferdig hele kravspesifikasjonen før man har tatt første spadetak, men hvor oppdragsgiver og entreprenør snakker sammen fortløpende under hele prosessen etterhvert som man ser hvor man havner.

    🙂

  2. Man bør ikke binde seg til en leverandør, men lage generell kravspesifikasjon. Allikevel vil vi få en kontinuerlig prosess, siden kravspesifikasjonen aldri vil bli helt ferdig, og utvikling av programvare likeså. I kontraktsperioden vil kravspesifikasjonen igjen bli oppdatert med nye ideer, rettelser og forbedringer. Hvis nåværende leverandør klarer å implementere elementer fra kravspesifikasjonen som har kommet inn etter kontraktsinngåelse er det bare bra. Å bestille noe man ikke helt vet hva er kan fort bli dyrt..

Leave a Reply

Your email address will not be published. Required fields are marked *