Det internationale netværk
for dig der arbejder med web eller intranet

Brug prosa til at formulere dine krav

23. november 2005 af Janus Boye | , , | Ingen kommentarer

Den australske ekspert James Robertson har en pragmatisk tilgang baseret på organisationens krav, der sikrer at krav kan dokumenteres på højst 20 sider! Dette står i stærk kontrast til de typiske kravspecifikationer, der nemt kan løbe op i flere hundrede sider og ligeså lange svar fra hver enkelt leverandør.

Share

I præsentationen startede James dog med at påpege, at der ikke er et enkelt system der passer bedst, i stedet er der mange produkter med meget forskellige muligheder og funktioner.

Den største risici er at vælge det forkerte system. Andre risici er grundet i usikkerhed, herunder:

  • svært ved at formulere krav
  • ukendt projektforløb
  • fejlslagne projekter i fortiden
  • ukendt fremtidig strategi og retning

Når man vælger et system er det mest typisk at man sammenligner de forskellige systemers funktioner. Dette fører til at man vælge det system, der kan mest. James foreslår i stedet, at man sammenligner baseret på krav. Han mener at dette har mange fordele samtidig med at det kan reducere risici.

Æbler og elefanter

Generelt opfordrer James til at man bør undlade at sammenligne produkter: “Det er ikke blot at sammenligne æbler med pærer, men nærmere at sammenligne æbler med elefanter!” sagde han.

James mener også at pris og ydelse sjældent hænger sammen. Det kan godt lade sig gøre at bruge mange penge på et system, der ikke kan særligt meget. Blot fordi man investerer mange penge i et system, er der ingen garanti for at projektet går godt.

Ifølge James er det vigtigt at huske at markedet for intranet, portal og CMS er ungt og umodent og de forskellige leverandører bruger begreber meget forskelligt. Af de eksisterende systemer har de 30 % ens funktionalitet og 70 % hvor de er forskellige. Disse store forskelle skyldes de meget forskellige baggrunde de enkelte systemer og leverandører har.

Før man går i gang med at vælge og indkøbe et nyt system, er det vigtigt at definere projektets omfang. Mange køber et system som de håber at kunne bruge for altid – dette er dog ikke realistisk, da egne krav vil ændre sig over tiden, ligesom markedet løbende ændrer sig. “Det er nemt at forestille sig, at der om få år vil komme et system på markedet, der er meget bedre end hvad der findes i dag” sagde James.

Kommunikation af behov

Der er stor forskel på hvad brugere fortæller om leverandører, samt hvad leverandørerne fortæller om brugerne. Skarpt illustreret af James, der kort listede 2 eksempler:

  1. Brugerne siger at leverandørerne fortæller alt muligt for at få solgt deres system
  2. Leverandørerne siger at brugeren vil læse alle mulige brochurer (uden nødvendigvis at forstå det) og bruge indholdet i deres kravspecifikation

Ifølge James, er det vigtigste at sikre at ens behov bliver forstået af leverandøren. Behov kan efter hans mening opdeles i:

  • funktionelle krav
  • tekniske krav
  • forretnings krav
  • hjemmeside/intranet karakteristika (der f.eks. kan illustreres som skærmdump)

De fleste kravspecifikationer indeholder hundredvis af funktionelle krav. Dette gør det oftere sværere at evaluere og vælge et system. Der er også den fare at dette unødvendigt fører til at man køber et alt for stort system.

I stedet for at gøre det på denne måde, så foreslår James at man fokuserer på nøglekrav, som der typisk er ganske få af. Mange misforstår normale krav med udvælgelseskriterier, hvilket fører til problemstillingen med lange kravspecifikationer der giver lange svar fra leverandører.

Slutteligt fortalte James, at det er vigtigt at beskrive hvad man vil have i et let forståeligt sprog, samt bede leverandøren beskrive hvordan, gerne med skærmbilleder.

Lær mere

Læs de mange andre artikler om valg af CMS eller læs om vores uvildige cms rådgivning.

Du kan også blive medlem af en erfa-gruppe, hvor du kan dele erfaringer med ligesindede.

Forfatter

Janus Boye

Som grundlægger af J. Boye, har Janus været med fra de første rådgivningsopgaveri 2003, de første erfa-gruppe møder i 2004, Århus konferencen hvert år siden 2005, opstart i England, erfa-grupper på tysk og meget mere.

Skriv en kommentar

Læs vores kommentarpolitik.