Kravspecifikation til websites

Jeg synes jeg har set for mange dårlige kravspecifikationer! Ofte er de ikke detaljerede nok til at udelukke tvivlspørgsmål. Andre gange ligner de en liste med idéer mere end kvalificerede krav.

Det skal vi have gjort noget ved! Jeg vil komme med input og idéer til, hvordan du bedre kan udfærdige en kravspecifikation eller måske nærmere en opgavebeskrivelse, som dit webbureau har nemmere at give dig økonomiske estimater på, fordi du har kredset nogle områder ind og gjort dine krav til din løsning mere præcise. Lad os se på det.

Introduktion til kravspecificering

For lige at kridte banen op, så skal vi lige have nogle statements slået fast:

  1. Du skriver ikke en kravspecifikation til dig selv
  2. Du skal være bevidst om din målgruppe – er modtagerne på
    • Leder niveau (direktøren, bestyrelsen o.lign.)
    • Mellemleder niveau (projektledere, chefer etc)
    • Udviklere
  3. Hvorfor du overhovedet laver en kravspecifikation

Udarbejdelsen af en kravspecifikation er helt grundlæggende et dokument som skal formindske tvivl og øge enighed omkring forventninger til løsningen.

Eksempel

Du spørger din chef: “Jeg vil gerne have fri.”

Din chef stiller dig flere spørgsmål: Hvornår, hvor længe, hvorfor

Kedeligt eksempel, men ikke desto mindre er dette sagens kerne, jo mere konkret du kan skrive dine krav og jo bedre de hænger sammen, jo mere solid er din beskrivelse og du har formindsket tvivl og øget muligheden for, at din leverandør forstår din løsning og kan forstå dine forventninger til løsningen.

Øget detaljeringsgrad

For mig er en kravspecifikation en opsummering af

  1. en analyse af dit behov
  2. en skitse af løsningen som du forstår den
  3. en beskrivelse af funktionerne i din skitse
  4. en beskrivelse af data anvendt i din skitse

Hvis dit behov er at lave en webshop for at øge omsætningen i forretningen, så er der en masse del-opgaver, som du skal sætte dig ind. et godt udgangspunkt er mange gange et kigge lidt på en anden webshop og så begynde at stille sig selv alle de spørgsmål om

  • Hvordan får jeg de rigtige varer på mit website?
  • Hvordan kan jeg levere fragtfrit?
  • Hvordan bliver jeg fundet via Google?
  • Hvordan får jeg loyale kunder?
  • Hvad appellere mine produkter til, pris, kvalitet andet?
  • etc.

Jeg kunne skrive en rigtig lang liste her. Fakta er, at du skal gøre det, både for din egen skyld og for dit projekts skyld. Hvis du ikke har tid til det, så få nogen til at gøre det for dig. Sæt dig så ned med dem og svar på alle spørgsmålene eller start en arbejdsgruppe op, som kan finde svarene for dig.

Nærmere løsningen

Det sværeste for nogen er at begynde at skitsere noget, men gør alt hvad du kan. Stregtegninger, håndtegninger, referere til andre websites, rutediagrammer, wireframe designs, bare gør noget – det skal ikke være perfekt, men understøttende for dine beskrivelser.

Når du har en skitse eller en hel masse skitser på forløb eller skærmbilleder, så kræver de ofte en forklaring og det bedste du kan gøre, er nøje at beskrive i en simpelt firkantet sprog alle de funktioner og elementer du skitseret.

Din skitsen sammen med funktionerne udgør en forventning til data. Hvor skal data komme fra? Der er rigtig mange hensyn at tage og det er måske den sværeste del at komme rigtig godt ud af det med, men hvad det bedste ved denne databeskrivelse er, at det er helt vildt nemt for sådan nogle som mig, at få stilt nogle borende spørgsmål til dine forventninger til vedligholdelse, opdateringsfrekvens, indholdet og redigeringsmiljø, hvis bare jeg har en skitse og en funktionsbeskrivelse, så giver det næsten sig selv.

Kravspecifikationen

Bør i min optik bestå af

  1. behovsanalysen
  2. skitsering af løsning
  3. funktionsbeskrivelsen
  4. databeskrivelsen

Så er dit udgangspunkt for at høre leverandører i kompetencer og pris meget bedre. For slet ikke at tale om, den sparring som du sikkert vil opleve og som en næsten uundværlig bonus – motivation fra dine teams.

Skriv gerne en kommentar, om det input jeg kommer med er noget du har tænkt dig at bruge?

Måske jeg kan følge op med flere detaljer på et senere tidspunkt.

,

15 Kommentarer

  • Potter siger:

    Alene ordet “Kravspecifikation” tager livet af mig – og mange andre tror jeg. Fordi det er vildt svært og ekstrem tidskrævende. Pointen er nok bare den, at bruger du ikke tiden inden… så kommer du til at bruge den efter….. og nok mere tid – og penge – når det er efter.

    Hvor kan man finde et godt eksempel på en kravspecifikation? Det kunne være lærerigt at se opbygningen af en god en af slagsen….

    Potter

  • Kevin Steffer siger:

    @Potter, at finde et godt eksempel på en kravspecifikation er problematisk, fordi udgangspunktet for at have lavet den næsten umuligt kan være den samme, men idéen er OK, så jeg vil tage udfordringen op og se om jeg kan finde eller lave et godt eksempel – jeg må kunne forklare mig ud af et fiktivt udgangspunkt.

  • Hørt hørt, jeg kender selv alt for godt til problematikken i for dårligt formulerede og uddybende kravspecifikationer, men det er selvf. ingen let opgave.

    En ting er i den teoretiske verden, men hvad med virkeligheden. Er det ikke svært at lave den “perfekte” specifikation?

  • René Madsen siger:

    At kunne beskrive og definere en opgave er vigtig inden for programmering, her kædes kundens ønsker sammen med rådgiverens ekspertviden indenfor området.

    Kravspecifikationen bliver en vigtigere del i al programmering, herved sikres kunden imod uhensigtsmæssig programmering og samtidig kan der bruges fasemodeller for udførsel af delelementer i opgaven, samt selve tidsstyringen i hele projektet.

    Sidst men ikke mindst, kunden sikrer sig økonomisk ved at få eksperter til at stå bag en kravspecifikation, at der er et sted de kan sende regningen, hvis der opstår problemer med det indhold der er beskrevet.

  • […] This post was mentioned on Twitter by Paw Poulsen, Kevin Steffer. Kevin Steffer said: Blogpost: Lav en bedre kravspecifikation til et website http://bit.ly/a52AXq […]

  • […] liggende i meget længe, og blev inspireret til at dele det efter at have læst blogindlægget http://websiteudvikler.dk/post/kravspecifikation-til-websites.html fra Kevin Steffer, som jeg følger på […]

  • Kasper Hamann siger:

    Super indlæg

    Jeg er helt enig. Jo mere konkret kunden udtrykker sine behov, krav og ønsker. Jo bedre.

    Jeg har lige lavet et hurtigt blogindlæg ud fra nogle noter jeg havde. Måske kan du blive inspireret af disse? Lad os fortsætte dialogen 😉

    Se mit indlæg på http://bør.se/a88HfC

  • Jeg har selv været i branchen i efterhånden rigtig mange år, og har i disse år set rigtig mange kravspecifikationer. Både gode og dårlige.

    Jeg kan derfor også efterhånden begynde at sige en del om succes/fiasko, og hvad der er årsag til hvad.

    Der er nogle, der vil argumentere for, at en 100% fyldestgørende kravspecifikation er alfa og omega. Og ja, hvis du har at gøre med et relativt velkendt domæne, og kunden er sat ind i det, så er det også en god måde at gøre det på.

    Men det suverænt største problem ved IT-projekter er, at kunden ofte ikke aner ret meget om domænet inden iværksættelse af IT-projektet. Og faktisk har jeg oplevet projekter, hvor aftageren af projektet havde svært ved at definere bare sine succeskriterier.

    Mine oplevelser er derfor, at hvis man kan være så heldig at lokke kunderne til det, så er en iterativ agil proces langt at foretrække. Naturligvis skal der være en række overordnede krav, men alle skal vide at tingene er til for at blive ændret. Vi er her jo for at lære og for at skabe et så succesfuldt projekt som muligt. Undervejs i projektet bliver kunden klogere, og udviklerne bliver klogere, og derfor kan vi komme tættere på et federe resultat.

    At det så er svært at få alle med på de agile tankegange er så en helt anden sag. :-) I de tilfælde er man nødt til at forsøge at indføre en “semi-agil” iterativ tankegang. Og her giver jeg dig 100% ret i, at bare det at starte med at tegne nogle streger på et stykke papir kan starte en særdeles frugtbar proces.

  • Kevin Steffer siger:

    @Kasper, Tak for at du deler det med os. Efter jeg læste Potters kommentar skal jeg helt klart også lige have gravet et real-world-worst-case kravspecifikation frem sammenlignet med en god én.

    @Michael og @Peter, en 100% fyldestgørende eller lad os kalde den en perfekt kravspecifikation kan man kun stræbe efter. Mange gange kan mindre gøre det, jo mere dialog der mellem kunde og leverandør jo mere begynder man jo at forstå hinanden, hvis der er en god kemi, hvilket jo i sig selv er en fantastisk gave i ethvert projekt.

  • Lisa Ingemann siger:

    Hej Kevin,

    Det er et rigtig interessant emne du skriver om her. Du har fat i rigtig mange gode ting i forbindelse med it-forundersøgelser.

    Jeg er selv i gang med at læse “Professionel it-forundersøgelse” af Bødker, Kensing og Simonsen, som jeg vil anbefale dig at læse – den er virkelig anvendelig.

  • Kevin Steffer siger:

    @Lisa, virkelig god bog! Har læst den, men jeg har desværre måttet forkaste mange gode intentioner på at bruge modellerne fra den, da de er meget IT fokuserede og ikke så agile eller web-agtige som jeg var på udgik efter.
    Men jeg fik udviklet min egen Projekt-Guide på baggrund af deres bog se det her:

    Projekt guide View more presentations from Kevin Steffer.

  • Allan siger:

    Kravspecifikationen er efter min overbevisning meget afgørende for om et projekt bliver en succes eller fiasko.

    Der kan være flere, der skal arbejde på et projekt, og har man ikke retningslinjer og behov beskrevet præcist, så kan løsningerne hurtigt blive løsninger, der leder efter et problem at løse, i stedet for at blive løsningen på det oprindelige problem.

    Jeg har særligt haft behov for at anvende kravspecifikationer i forbindelse med outsourcing af mindre it-projekter, hvor projekterne sendes til lavtlønslande. Her kan kravspecifikationen anvendes til at holde leverandøren op imod, hvad der er aftalt, når der engang imellem bliver leveret noget, som ikke dækker behovet.

  • Peter Lauge siger:

    Mange af vores kunder får sved på panden når vi siger ord som kravspek. Vi vil ikke skræmme vores kunder, så vi kalder det for en projektbeskrivelse.

    Den er lidt lettere for dem at forstå. At de så har svært ved at forstå at de skal betale for at få lavet en projektbeskrivelse, er en anden snak :-)

    Det er svært med ikke tekniske kunder. For de har nogle forventninger de ikke kan sætte ord på, men først forstå det når det endelig produkt er færdigt. Og har man ikke en glad kunde når projektet afslutes, så er den kunde nok historier og ikke nogen god ambasadør.

    Men vi skriver nu altid en projektbeskrivelse alligevel, selv om vi ved kunden ikke læser eller gider bruge tid på at forstå den. Og så afsætte vi altid noget tid til evt. at please kunden til sidst.

    For glade og tilfredse kunder kommer oftere igen end sure og skuffede kunder :-)

  • Jeg synes det sværeste i kravsspec’en er, at huske alle småtingene. Jeg mener ikke, at jeg kan tage højde forenhver lille bitte detalje, og derfor leder jeg (stadigvæk) efter en proces, der kan fange de vigtigste ting, og stadig give mulighed for, at tilrette ting løbende – det er endnu ikke helt lykkedes mig, især ikke, når jeg arbejder med flere underleverandører.

    Er der nogen af jer der har nogle tips til, hvordan man kommer omkring de små detaljer, uden at bruge uforholdsmæssigt meget tid på ligegyldigheder?

  • Allan Hansen siger:

    Helt sikkert et godt indspark.

    Jeg er enig med Ib’s kommentar om, at hvis ikke man bruger tiden på at specificere sin opgave, inden man sender den videre, så kommer man bare til at bruge tiden bagefter.

    Kravspec’en er også fantastisk god til at forhandle pris ud fra. Det gør nemlig, at man kan forhandle om en pris på et bestemt stykke arbejde, i en bestemt kvalitet til en bestemt leveringstid – frem for at skulle diskutere frem og tilbage baseret på tillid. Det er lettere for både indkøber og leverandør.

    En kravspec skal dog ikke altid anvendes. Det er rigtig mange situationer, hvor kravspeccen er forældet inden man kan få sin løsning leveret, og derfor kan det være bedre at anvende en mere agil metode til samarbejdet, f.eks. scrum.

    Venlig Hilsen
    Allan

Skriv et svar

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>