Teknisk kravspecifikation: De afsnit, der ofte mangler

En kravspecifikation, der kun beskriver, hvad kunderne skal kunne se og gøre, mangler halvdelen. Det er i de tekniske afsnit – data, integrationer, migrering, hastighed, sikkerhed, tilgængelighed, drift og accept – at de dyre misforståelser opstår. Ikke fordi leverandøren snyder, men fordi ingen har skrevet ned, hvad der forventes.

Artiklen handler kun om de tekniske afsnit. Den samlede metode – fra problem og brugerrejse til prioritering – står i guiden til kravspecifikation med skabelon, og du kan gennemgå det hele med tjeklisten.

Hvad, ikke hvordan

Også i de tekniske afsnit skal du beskrive hvad der skal opnås og lade leverandøren foreslå hvordan:

• Godt: “Lagerstatus på webshoppen skal svare til lagersystemet, før kunden lægger varen i kurven.”
• Mindre godt: “Der skal laves et webhook fra lagersystemet.”

Det første kan leverandøren løse på den bedste måde. Det andet låser løsningen, før nogen har set på den.

1. Data

Hvilke data findes, og hvor bor de?

• Produkter: antal, varianter, felter ud over standard, billeder, oversættelser.
• Kunder: konti, adresser, samtykke til markedsføring, B2B-priser.
• Ordrer: hvor mange års historik skal med, og skal den kunne bruges eller bare arkiveres?
• Master: Hvilket system ejer hvad? Produktdata i ERP eller PIM, priser i ERP, kunder i webshoppen?

Det sidste spørgsmål er det vigtigste. Når to systemer begge mener, de ejer en pris, ender du med fejl.

2. Integrationer

For hver integration:

• Systemer: fra hvad til hvad – fx webshop til regnskab, lager eller fragt.
• Data: hvilke felter, og i hvilken retning.
• Hvor ofte: med det samme, hvert kvarter eller en gang i døgnet?
• Fejl: Hvad sker der, når integrationen fejler? Hvem får besked, og hvordan rettes det?
• Volumen: antal ordrer og produkter i dag og om et par år, også på de travleste dage.

Vælg integrationer, du kan komme videre fra. Krav til API, dataeksport og exit har jeg samlet i artiklen om integrationer uden lock-in.

3. Migrering

Skifter du platform, skal kravspecifikationen beskrive:

• hvilke data der flyttes, og hvordan resultatet kontrolleres
• redirects: at alle eksisterende URL’er sendes videre med 301-redirects til den nye side
• titler, beskrivelser og andet indhold, der skal bevares
• kundekonti og adgangskoder – hvad kunderne skal gøre efter skiftet
• en plan for lanceringsdagen og de første uger

4. Hastighed og stabilitet

“Siden skal være hurtig” kan ikke testes. Skriv i stedet:

• hvilke sidetyper der måles – fx forside, kollektion, produkt og kurv
• med hvilket værktøj – fx PageSpeed Insights eller Core Web Vitals fra rigtige brugere
• hvilken grænse der skal overholdes, og på mobil eller computer

Google beskriver brugeroplevelsen med Core Web Vitals for indlæsning, reaktionstid og visuel stabilitet. Det er et godt fælles sprog med leverandøren. Beskriv også forventningerne til de travleste dage, fx Black Friday.

5. Sikkerhed og persondata

• Adgange: Hvem får adgang til hvad? Leverandøren bør have egne konti, ikke dit login.
• Persondata: Hvilke persondata behandler løsningen, og hvilke leverandører behandler dem på dine vegne? Det kræver databehandleraftaler.
• Cookies og samtykke: Hvilke scripts kræver samtykke, og hvordan styres de?
• Opdateringer: Hvem holder apps, plugins og kode opdateret efter lancering?

6. Tilgængelighed

Tilgængelighedsloven gælder bl.a. for e-handelstjenester til forbrugere fra 28. juni 2025. Mikrovirksomheder, der tilbyder tjenester, er undtaget: under 10 personer og enten en årsomsætning eller en samlet balance på højst 2 mio. euro. Er du omfattet, skal kravet stå i specifikationen, så leverandøren prissætter det. Er du i tvivl, så få det vurderet.

7. Drift, ejerskab og dokumentation

• Ejerskab: Butikken, domænet, koden og alle konti står i dit navn.
• Kode: i et repository, du har adgang til.
• Dokumentation: af tilpasninger og integrationer, nok til at en anden udvikler kan overtage.
• Drift efter lancering: fejlretning, svartider ved kritiske fejl og hvem der overvåger integrationerne.

Kontraktdelen af det har jeg beskrevet i artiklen om vilkår i bureaukontrakter.

8. Test og accept

Hvordan godkender du leverancen?

• Acceptkriterier for hvert krav, så det er tydeligt, om det er opfyldt.
• Testscenarier: fx en ordre med rabatkode, en ordre til pakkeshop, en returnering og en ordre, der fejler i betalingen.
• Testdata og testmiljø, så der ikke testes på rigtige kunder.
• Hvem tester hvad, og hvor lang tid du har til at godkende.

Et eksempel på et godt acceptkriterium: “En ordre i webshoppen står i regnskabssystemet med korrekt moms og betalingsmetode senest dagen efter. Testes med ti testordrer med forskellige betalingsmetoder.”

Typiske fejl

• Løsningen i stedet for behovet. Beskriv, hvad der skal opnås.
• Ingen master. To systemer, der begge ejer de samme data.
• Kun det glade forløb. Hvad sker der, når noget fejler?
• Ingen volumen. Det, der virker ved ti ordrer, holder ikke nødvendigvis ved tusind.
• Ikke-funktionelle krav glemt. Hastighed, sikkerhed og tilgængelighed bliver dyre at tilføje bagefter.

Hvor detaljeret?

Så detaljeret, at to leverandører kan give tilbud på det samme. En lille integration kan beskrives på et par sider. Et platformskifte kræver mere. Det handler om præcision, ikke sideantal.

Når specifikationen er sendt

Bed leverandøren opsummere kravene med egne ord. Gode leverandører stiller opklarende spørgsmål – det er et godt tegn. Når tilbuddene kommer, kan du bruge min metode til at vurdere tilbud fra bureauer.

Opsummering

De tekniske afsnit er der, hvor projekter vindes eller tabes. Beskriv data og master, integrationer med fejlhåndtering, migrering og redirects, målbare krav til hastighed, sikkerhed og tilgængelighed, ejerskab og drift – og hvordan leverancen godkendes.

Vil du have hjælp til de tekniske afsnit eller en uafhængig gennemgang, før du sender specifikationen ud, kan du læse om min rolle som ekstern CTO.