Asynkron webkommunikation

Forudsætningen for en succesfuld implementering af et Content Management System er, at man har skrevet en god kravspecifikation. Jeg har de sidste 7 år arbejdet med at udvikle og sælge CMS, og derfor har jeg i tidens løb set både gode og dårlige eksempler på, hvordan kravspecifikationer bliver skrevet. Her er et par råd, der er baseret på mine erfaringer:

1. Fokuser på behovene – ikke funktionerne
Mange kravspecifikationer beder om meget konkrete funktioner. Problemet med dette er, at det tvinger leverandørerne til at lave tilbud baseret på en udvikling, der ligger fuldkomment op ad det beskrevne. Dermed er der risiko for, at andre – og muligvis billigere – løsninger bliver overset, selvom de opfylder samme behov for kunden.

2. Fokuser på værktøjet – ikke websitet
Selvom de fleste interne diskussioner hos kunden forud for kravspecifikationen typisk drejer sig om, hvordan det nye website skal se ud og fungere, skal man som kunde tænke på, at det sikkert ændrer sig, lige så snart den første implementering er gennemført. Derfor er det langt vigtigere at bruge ressourcerne på at afklare krav til det værktøj, der skal publicere websitet i flere generationer fremover end på den føreste implementering.

3. Lav en god vejledning til dem, der skal besvare kravspecifikationen
Det er vigtigt at hjælpe leverandører ved at forklare dem, hvordan de skal besvare kravspecifikationen. Er der et fast skema, der skal udfyldes? Hvordan forstår I selv nøglebegreber? Hvor meget dokumentation skal leveres med?

4. Fortæl hvad der er krav, ønsker og rart at have
Alle jeres krav er sandsynligvis ikke missionskritiske, så hjælp leverandørerne ved at angive, hvilke krav der *skal* opfyldes, hvilke der *ønskes* opfyldt og hvilke, der blot er *rare* at få opfyldt. Leverandører vil nemlig lægge mere energi i at få beskrevet, hvordan de vil opfylde de obligatoriske krav end dem, der er blot er rare at få opfyldt.

5. Opstil krav til performance – men angiv forudsætninger
Det er vigtigt, at det opstilles krav til systemet performance (antal samtidige brugere, responstid for sidevisninger og operationer med videre), men kravene er meningsløse for leverandørerne, hvis forudsætningerne ikke er angivet præcist. Hvor “tung” antages en side at være (i kb)? Hvor mange besøgende er på serveren samtidig? Hvilke typer af operationer? Hvilken server antages være stillet op (processor, RAM og så videre)? Jo flere forudsætninger du angiver, desto mere præcist vil leverandører være villige til at svare. Hvis du ikke angiver forudsætninger for performancekrav, vil leverandører bare svare fuldkomment uforpligtende i stil med “systemet antages at kunne opfylde de beskrevne krav”…

6. Brug use cases for de vigtigste brugsscenarier
Use cases er gode, fordi de støtter beskrivelsen af krav. Det gør det væsentligt nemmere for leverandører at forstå, hvilke problemer der skal løses i hvilken kontekst. Men lad være med at drukne kravspecifikationen i use cases – brug dem for de vigtigste brugsscenarier.

7. Beskriv leverancens omfang detaljeret
Der er meget stor prismæssig forskel på at købe et CMS og implementere det selv og så at købe et system med fuld implementering – og der er uendeligt mange varianter i mellem. Beskriv hvad I vil have leverandøren til at levere, og hvad I selv vil klare. Bed eventuelt leverandørerne estimere opgaver, I selv vil løse, så I får en idé om, hvor vanskeligt og ressourcekrævende de forskellige dele af implementeringsarbejdet er for de tilbudte systemer.

8. Beskriv det videre forløb
Leverandører er interesserede i at vide, hvordan den videre proces forløber. Kan der stilles spørgsmål til kravspecifikationen? Hvornår skal tilbud indleveres? Vil der være mulighed for at præsentere systemet efter tilbud er afleveret? Hvornår forventes beslutning at træffes?

9. Hvilke standarder skal overholdes?
For mange kravspecifikationer indeholder ingen krav til standarder, men det er vigtigt at forklare hvilke standarder, der skal overholdes, fordi det får betydning for, hvilke andre systemet CMS’et kan bindes sammen med. XML? SOAP? XHTML? tilgængelighed?

10. Få hjælp!
Det er vigtigt at få eksterne øjne på en kravspecifikation i udarbejdelsesfasen, men det behøver ikke at betyder, at den nødvendigvis skal skrives fuldstændigt af eksterne konsulenter. Eksterne øjne sikrer, at kravspecifikationen ikke kommer til at indeholde indforståede begreber, og at I får diskuteret jeres forretningsmæssige mål grundigt. Endelig er eksterne øjne oftest den bedste garant mod “politiske/symbolske” krav, der kommer med, blot fordi en chef uden reel grund insisterer på det.

Denne artikel blev publiceret Wednesday d. 7. July 2004 kl. 22:45 under , . Du kan følge alle svar til denne artikel via RSS 2.0 feed. Du kan hoppe til slutningen og skrive et svar. Pinging er ikke tilladt i øjeblikket.