Indledning
Denne artikels mål er at gøre dig i stand til at skrive en god brugbar kravspecifikation til brug i forbindelse med udvikling af IT Projekter. Dette er en opgave, man som projektleder eller virksomhedsleder stik i mod manges forventninger sagtens kan gøre selv. En kravspecifikation drejer sig nemlig ikke om at lave en punktlig arbejdsplan til programmøren, men derimod om at definere de krav du som kunde stiller til det endelige projekt.

Det er derfor vigtigt, at du beskriver, hvad du ønsker af systemet, og ikke hvordan systemet skal løse det. Det er programmøren, der besidder kompetencen til at tage beslutning om, hvilken datalogisk algoritme, der er bedst til at løse en given problemstilling.

Det er også vigtigt at fastslå, at en kravspecifikation ikke er et udbudsmateriale! Det kan imidlertid indgå som en del af en kravspecifikation. Teknisk indsigt er ofte en ulempe, når man skal skrive en kravspecifikation. Det endelige mål med et IT-udviklingsprojekt er for det meste at automatisere en normalt manuelt udført arbejdsgang, derfor er den vigtigste kompetence for personen, som definerer projektet, ikke datalogisk kendskab, men derimod kendskab til den arbejdsgang, som skal automatiseres.

Den overliggende kravspecifikation
Overliggende består en kravspecifikation af de funktionelle krav, de ikke-funktionelle krav herunder performancebegrænsninger og projektbegrænsninger, og slutteligt løsningsmål. Ved store projekter kan det muligvis gavne helhedsforståelsen at lave flere små kravspecifikationer, f.eks. ved. en hjemmeside, hvor der findes flere forskellige typer interaktive funktioner, kan det hjælpe at lave en række delspecifikationer, som samles i en overordnet kravspecifikation.

Du skal tænke på, at leverandøren som oftest ikke får betaling for at læse din kravspecifikation igennem, så den skal være nem for ham at læse, han skal hurtigt kunne sætte sig ind i din tankegang, og sidst men ikke mindst er det vigtigt at undgå gentagelser og overlappende punkter.

De funktionelle krav
Er en liste over de funktioner, som du ønsker at systemet skal kunne udføre; det kunne f.eks. være:

  • Systemet skal kunne opbevare og indsamle vejrdata fra vejrstationen.
  • Systemet skal løbende beregne og præsentere gennemsnit, statistikker og forecasts.

Disse krav beskriver ønskede funktionaliteter og kaldes derfor for de funktionelle krav. De funktionelle krav skal være så korte og præcise som muligt.

Det er her vigtigt, at du ikke forsøger at beskrive, hvordan opgaven skal løses, men udelukkende beskriver opgaven, dvs. følgende punkter er helt udelukket:

  • Systemet skal udvikles i PHP
  • Systemet skal anvende en MsSQL Server

Der findes ingen gyldig årsag til at stille sådan et krav, for der ligger altid et overordnet krav til grund for disse, det kunne f.eks. være.

  • Systemet skal kunne afvikles på vores eksisterende server.
  • Systemet skal være portabelt, således at det kan afvikles på majoriteten af markedets webservere.

Disse krav bør dog altid nedprioriteres, da udviklerens handlefrihed begrænses proportionelt med antallet af denne type tekniske krav. Dette leder videre til prioriteringen af kravene i kravspecifikationen:

I langt de fleste projekter er det rigeligt at anvende høj, mellem og lav prioritering. Kun ved meget store projekter giver det mening at graduere prioriteringen yderligere. Samtlige grundlæggende krav skal være højeste prioritet, det vil sige de krav, der definere grundfunktionen i systemet.

Derfor vil de endelige krav typisk kunne se ud som følger:

  • Prioritet: høj, Systemet skal indsamle vejrdata fra vejrstationen. Ved hjælp af den indkøbte hardware (Bilag 1 indeholder dokumentation) skal der løbende indsamles vejrdata.
  • Prioritet: høj, Systemet skal udføre beregninger på baggrund af de indsamlede data med henblik på udvikling af statistikker og forecasts. Metoderne pattern og Numeric Weather Prediction (NWP) skal anvendes til dette, disse metoder er detaljeret beskrevet i Bilag 2.

Ikke funktionelle krav
Disse krav beskriver forskellige typer begrænsninger. Begrænsninger kan lyde som en underlig ting i en kravspecifikation, men en begrænsning eller en afgrænsning kan også være en specifikation. Hvis vi f.eks. siger .Kunden skal kunne betale med Visa Kort og Master Card. har vi samtidig udelukket American Express. De ikke funktionelle krav er også opdelt i 2 typer. Nemlig Performancebegrænsninger og Projektbegrænsninger.

Performancebegrænsninger
Disse krav handler om systemets performance når det først er leveret. Det drejer sig om at begrænse antallet af mulige løsningsmåder. Her er ofte tale om mere specifikke krav. Det kan f.eks. være:

  • Prioritet: høj, Kunden skal kunne betale med Visakort, Dankort samt Bankoverførsel Brugeren skal have valget mellem disse betalingsformer, det bemærkes at bankoverførsel kun må tilbydes erhvervskunder.
  • Prioritet: mellem, Systemet skal være tilgængeligt døgnets 24 timer Der må altså ikke være planlagt .nedetid. f.eks. hver nat . dvs. al vedligeholdelse skal køres uden gene for brugeren.

Det er vigtigt at disse krav begrænser udviklerens måder at løse opgaven, men uden at diktere, hvordan denne skal løses. Det vigtigste her er dog at tage udgangspunkt i virksomhedens behov.

Projekt begrænsninger
Desværre har man sjældent ubegrænsede midler til rådighed i forbindelse med udviklingen af et IT projekt. Det er derfor nødvendigt at opstille nogle begrænsninger for projektet. De vil typisk indeholde ressourcemæssige begrænsninger, dvs. økonomi, tidsmæssige begrænsninger altså deadlines og til slut kvalitetsbegrænsninger. Det kunne f.eks. Se sådan ud:

  • Prioritet: høj: Prisen for udviklingen må ikke overskride 150,000 DKR
    Der er vedlagt et detaljeret budget som Bilag 3.
  • Prioritet: mellem: Projektets endelige deadline er d. 1-1-2008.
    Der er vedlagt et detaljeret Gantt kort som Bilag 4
  • Prioritet: lav: Det foretrækkes at systemet kan afvikles på eksisterende server
    Virksomhedens eksisterende server er en Windows 2003 Server med ISS 5.0

Beskrivelsen af et Gantt kort kan læses på følgende adresse: http://en.wikipedia.org/wiki/Gantt_chart. Det er vigtigt at have lav prioritet på sidste begrænsning, da en udvidelse af Windows Serveren eller anskaffelse af en ny i nogle tilfælde vil kunne betales af den besparelse, der kan opnås ved at vælge en anden teknologi.

I forbindelse med de forskellige begrænsninger, skal du ud over det åbenlyse tænke på følgende:

  • Ressourcer: Med udtrykket ressourcer skal der ikke kun tænkes på økonomiske resourcer, der skal også overvejes tilgængeligheden af kvalificeret mandskab, licenser, hardware mv., samt antallet af udbydere af en eller flere af de brugte teknologier. Et krav, som bør indgå i de fleste længerevarende projekter, er kravet om uafhængighed fra en udbyder, dvs. projektet må ikke være afhængig af en ressource, som kun en bestemt leverandør kan levere.
  • Kvalitet, her kan være tale om browserkompatibilitet, sikkerhed, brugervenlighed, kodekvalitet med videre. De typiske krav vil dreje sig om struktureret og overskuelig kode med henblik på fremtidig videreudvikling, evt. af en anden udvikler . altså i forbindelse med en potentiel fritstillelse af kunden, der så alligevel har et brugbart projekt, jf. forrige punkt med leverandøruafhængighed, hvor netop Udviklingshuset er en væsentlig leverandør.

Løsningsmål
Til slut skal du beskrive de vigtigste mål for sitet: På hvilket område ønsker du at lægge hovedvægten. Erfaringen siger, at såfremt du ikke vælger det, vil designerne, udviklerne eller projektlederne gøre det. Dit løsningsmål kunne f.eks. være, at du ønsker .hurtig og smertefri behandling af alle kundeforespørgsler., hvor en designer f.eks. kunne vælge at lægge fokus på designet. Et stort og flot design er typisk med til at gøre afviklingen af systemet langsomt, og derfor vil det modarbejde dit løsningsmål. Derfor er det meget vigtigt at du specificerer dette.

Eksplorative kravspecifikationer
Hvis du er på det stadie i processen, hvor du ikke helt har fået præciseret dine krav, eller ønsker at afsøge mulighederne inden for dine økonomiske grænser, kan du lave en kravsspecifikation, hvor du definerer budget, vilkår mv. Herefter opgiver du de forskellige funktionelle og ikke-funktionelle krav og prioriterer dem som følger:

  • Must have
    Krav der skal opfyldes, uden diskussion. Der kan ikke fraviges fra dem overhovedet.
  • Should have
    Krav der skal opfyldes såfremt det er muligt.
  • Could have
    Krav der kan opfyldes, såfremt det ikke kompromitterer andre dele af kravsspecifikationen.
  • Would be nice to have
    Features der vil være rare at have, men som kun ønskes såfremt det ikke forøger resource forbrug eller kompromitterer nogen som helst andre krav.

Herudfra har udviklerne så mulighed for at sammensætte et tilbud og sammensætte en konfiguration, som de mener kan løse din opgave på bedst mulig måde. Du han så herefter vælge den leverandør med den for dig bedste løsning, eller du kan redigere din kravsspecifiktion og bede virksomhederne vurdere den på ny.

Opsummering
Følgende er eksempler på dårlige eller uklare krav:

  • Systemet skal være sikkert.
  • Sitet skal overholde samtlige W3C Standarder.

Umiddelbart lyder det som gode krav, men et .sikkert system. er uklart. To menneskers vurdering af begrebet .et sikkert system. er sjældent det samme, ligesom det er svært for et og samme system at overholde samtlige W3C Standarder, da mange af dem er direkte modsigende.

Læs gerne din kravspecifikation igennem dagen efter du har skrevet den. Du vil sandsynligvis komme på ideer til ting, du ikke før havde tænkt på. Tænk på, at ham der læser din kravspecifikation ikke nødvendigvis har samme baggrund som dig. Vær derfor varsom med at bruge fagudtryk fra DIN branche.

Tænk samtidig på at ham, der læser din kravspecifikation, typisk har mange års erfaring fra SIN branche, derfor skal du undgå at bruge fagudtryk fra hans branche, idet du sandsynligvis ikke har styr på den fulde betydning af samtlige fagudtryk. Hvis du alligevel anvender dem, indikerer du indirekte, at du ved, hvad du taler om, hvilket ikke er smart og kan give yderligere forvirring, med mindre dette rent faktisk er tilfældet.

Ved at følge disse forholdsvis enkle regler, øger du chancen for ikke at skulle holde timelange møder, for at projektere en given opgave og du undgår kommunikationsproblemer, og dermed skulle risikoen for at ende med et kuldsejlet projekt være minimeret ganske betragteligt. Dvs. du udfører selv en del planlægning, men får til gengæld også en helt anden garanti for, at du ender med at få det produkt, som du selv havde forestillet dig.