Jeg har gennem tiden skrevet et utal af tilbud baseret på udbudsmateriale, der var mere eller mindre gennemarbejdet.
Desværre har de fleste kravspecifikationer en stor fejl:
- De funktionelle krav har været skrevet i hvordan-form i stedet for hvad-form
Når man skriver kravspecifikation for funktionelle krav, er det en kunstform kun at beskrive det som systemet skal kunne (altså selve forretningskravene) og ikke hvordan systemet forventes at løse disse krav.
Når funktionelle kravspecifikationer er skrevet i hvordan-form giver det store vanskeligheder at udnytte standardsystemer til at løfte krav der dybest set kan håndteres af standardfunktionalitet, fordi der i kravene er indlagt krav til proces og præsentation.
Det bedste i sådan en stituation er at indgå i tæt dialog med kunden og gennem workshops søge at forstå selve hvad-essencen i kravene. Herefter er det så muligt via prototyping at vise hvordan krav kan løftes f.eks. via standardfunktionalitet.
Jeg kalder processen for “Transformation af forretningskrav med fast overfladeareal”. Det handler i virkeligheden bare om at forstå de basale forretningskrav og vise hvordan de kan løftes nemmest via standardfunktionalitet. Jeg har gennemført workshops med dette formål med masser af kunder. Senest med Københavns Universitet, hvor vi fik reduceret omkostningerne til projektet med næsten 25% ved, at løse krav med standardfunktionalitet, i stedet for at kode en løsning der opfyldte de oprindelige krav 100% uden brug af standardfunktionalitet.
Processen kan bruges i alle situationer, hvor der er tale om en løsning, hvor det er muligt at bruge et standardsystem til at løse store dele af forretningskravene.
