Eksempler på dårlige krav

Dårlige krav er typisk kendetegnet ved at være enten for uklare eller for specifikke. Det vil sige, at de ikke spidser de funktionelle krav til, eller at de forsøger at fortælle udvikleren, hvordan han eller hun skal gøre sit arbejde. Eksempler på uklare krav kunne lyde:

• Systemet skal være brugervenligt
• Sitet skal leve op til alle W3C’s standarder

Disse krav kan se fornuftige ud ved første øjekast, men hvad betyder ”brugervenligt”, og hvilke W3C-standarder taler vi om? Begge disse ”krav” optræder i ca. 60 % af de udkast til kravspecifikationer, som jeg ser i mit daglige arbejde i Infoark.

Eksempler på krav, der er for specifikke, kunne lyde:

• Kundedatabasen skal køre på my
• SQLRecords for hver kunde skal have separate felter for titel, fornavn, efternavn, gade...
• Systemet skal programmeres i PHP

Også disse krav kunne virker fornuftige. Problemet er, at du ikke kan vurdere, om de giver mening, før du har set en række løsningsmuligheder fra de kompetente udviklere.

Prioritering af krav

Når man har samlet listen af krav og defineret dem nærmere, skal de prioriteres. Deadlines, ressourcer og andre omstændigheder gør, at du næppe kan få alt, hvad du ønsker dig. Men det skal være dig, der prioriterer, hvad der er vigtigst og hvad der er ønskeligt. Hvis du ikke foretager prioriteringen, bliver afgjort af tilfældige omstændigheder, eller udviklerne vil være bestemmende. Måske vil de lave det hele eller blot de dele, der er nemmest eller billigst. Under alle omstændigheder kan du ikke være sikker på, at de krav du finder er de vigtigst, bliver prioriteret højest. Du prioriterer de enkelte krav efter fire kriterier. Skalaen (eller princippet) kaldes for MoSCoW.

• Must have: Krav der skal opfyldes
• Should have: Krav der skal opfyldes, hvis det kan lade sig gøre
• Could have: Krav der kan opfyldes, hvis anførte begrænsninger ikke påvirkes
• Won’t have: Krav du stiller til systemet, men som først skal opfyldes i en senere version

Ved at foretage en prioritering på denne måde, signalerer du i et klart sprog, hvad der er vigtig for dig og din organisation. Prioriteringen tager udgangspunkt i din opdeling i krav og begrænsninger. På den måde fremstår den klar og enkel, og er nem at forstå.

Klar, parat, SKRIV!

Mennesker arbejder naturligvis forskelligt, men det er min erfaring, at det er en god idé at påbegynde skriveprocessen tidligt. Naturligvis ligger der et væsentligt forarbejde i at bestemme hvilke krav, der er vigtige for dig og din organisation. Men nu, hvor du har et bilede af, hvordan kravspecifikationen skal struktureres, kan du lige så godt begynde at skrive på et levende dokument tidligt i processen.

Lad os opsummere:

En gennemtænkt kravspecifikation er altså helt afgørende for, at dit IT-projekt kommer sikkert i mål. Den gode nyhed er, at det ikke kræver specielle tekniske kompetencer at lave en kvalificeret kravspecifikation. Den behøver heller ikke at være en tyk og detaljeret bibel, der beskriver alle omstændigheder omkring løsningen. Faktisk er arbejdet lige til at gå til. Hvis man går systematisk til værks.

Den gode kravspecifikation består overordnet af tre dele:

• Funktionelle krav
• Ikke-funktionelle krav
• Løsningsmål

Det er vigtigt at de enkelte krav prioriteres. Og husk; kravspecifikationen skal ikke fortælle hvordan systemet skal virke, men hvad systemet skal levere.

Du er nu være klædt på til at komme godt fra start. Hvis du får brug for hjælp til at komme helt i mål, er du velkommen til at kontakte Infoark for assistance.

God arbejdslyst.

< Forrige side