Hvad består kravspecifikationen af?

I virkeligheden behøver man ikke en masse teknisk indsigt for at specificere krav; tvært imod kan det være en ulempe. Hvorfor vil du forstå senere. Men efterhånden som du begynder at specificere, hvad det er, du vil have eller ønsker at opnå, begynder det tekniske sprog trods alt at nærme sig en smule. Men frygt ikke – det er lige til, hvis man deler det lidt op. For at opnå det størst mulige overblik, arbejder vi hos Infoark med tre hovedpunkter, som er opdelt i en række underpunkter. Her vil vi blot beskrive hovedpunkterne og de generelle principper. Hovedpunkterne er:

• Funktionelle krav – hvad skal systemet kunne
• Ikke-funktionelle krav – forskellige begrænsninger
• Løsningsmål – retningslinier til at vælge den rette løsning

Funktionelle krav

De funktionelle krav er en liste over de funktioner, som du ønsker, at systemet skal kunne udføre. I den videre tekst vil vi bruge en e-commerce løsning som eksempl. Her kunne et krav lyde:

• ”Systemet skal kunne gemme alle detaljer om kundens ordrer.”

Det vigtige er, at man beskriver hvad man ønsker af systemet og ikke hvordan systemet skal løse opgaven.

Hvis du synes det lyder lidt for simpelt, så læs videre. Det giver mening efterhånden som dette funktionelle krav sættes ind i en sammenhæng.

Ikke-funktionelle krav

Måske har du hørt begrebet ”ikke-funktionelle krav” før. I dårlige kravspecifikationer optræder de i form af besynderlig indforstået snak. Men ikke-funktionelle krav er egentlig ganske simple. Det er en beskrivelse af nogle forskellige begrænsninger vi sætter for løsningen og den måde den kan bygges på. Formålet er ganske simpelt at begrænse løsningsmulighederne. For i princippet er der jo mange måder at løse dine funktionelle krav på. Alt for mange. Som du så, kan de funktionelle krav være ret overordnede, fordi der her tages udgangspunkt i organisationens behov.

For overblikkets skyld, deler vi de ikke-funktionelle krav op i to; performancebegrænsninger og projektbegrænsninger.

1: Performancebegrænsninger

Performancebegrænsninger handler om, hvordan systemet skal performe når det først er leveret. Krav til en e-commerce løsning uden nogen som helst begrænsninger, kunne både resultere i en løsning, der håndterer internationale kunder med kreditkortbetaling osv., men også en løsning kun for lokale kunder, der betaler per efterkrav. For at begrænse mulighederne, tilføjer man en række betingelser, der skal opfyldes. De kan angå kapacitet, skalerbarhed, tilgængelighed osv. Eksempler på performancebegrænsninger kunne være følgende:

• Kunden skal kunne betale med kreditkort og Dankort
• Forsendelsesadressen skal verificeres mod faktureringsadressen
• Kunden skal modtage en mail, der bekræfter bestilling
• Systemet skal være tilgængeligt fra 04:00 til 00:00
• En kunde-record skal være tilgængelig i minimum syv år

Man kan tænke sig en lang række øvrige betingelser at tilføje. Det vigtige her er, at disse betingelser begrænser udviklerens løsningsmuligheder. Men stadig med udgangspunkt i organisationens forretningsbehov. Og uden at anvise, hvordan udvikleren skal løse sin opgave. Det vil bringe dig tættere på en løsning, der leverer det, du havde forestillet dig.

2: Projektbegrænsninger

Ud over performancebegrænsningerne er det en god idé at inkludere nogle begrænsninger for selve IT-projektet. Desværre er det jo sådan, at eksterne faktorer har stor betydning for, hvilken løsning man får ud ”i den anden ende”. Især i store, komplekse eller politiserede organisationer. Hos Infoark bruger jeg et mere komplet sæt af værktøjer til håndtering af disse udfordringer. Her vil vi blot bryde ned i tre klassiske projektbegrænsninger:

• Ressourcer – økonomi er her det første man tænker på, men lige så vigtigt er adgangen til kvalificeret mandskab og relevante ledere og nøglepersoner.
• Tid – hvornår skal løsningen være færdig.
• Kvalitet – det kan i denne sammenhæng være niveau af brugervenlighed, browserkompabilitet, inddragelse af interessenter mv.

Løsningsmål

Løsningsmål hjælper dig til at vælge en løsning ud fra den række af muligheder, du har. Kun du ved, hvad der er de vigtigste features for et nyt system. Er det performance? Er det skalerbarhed? Er det brugervenlighed? Det ville jo være rart, hvis man kunne få det hele, men naturligvis må man prioritere. Og det skal gerne være dig, der foretager denne prioritering. For hvis du ikke gør det, vil udviklerne gøre det. Det viser alle erfaringer.

I forbindelse med e-commerce projektet kunne et primært løsningsmål for eksempel være, at brugerne skal kunne gennemføre købstransaktionen hurtigt og smertefrit. Hvis dette er det væsentligste løsningsmål for dig og din forretning, skal du udtrykke det klart i kravspecifikationen. Ellers risikerer du, at udviklerne prioriterer seneste teknologi eller at designerne lægger vægt på smart design på bekostning af effektivitet.

< Forrige side Næste side >