Kravsporbarhed: fra kravspecifikation til test som bevis

Forside · Gennemgået oktober 2026 · Af John Nielsen

Kravsporbarhed er evnen til at følge et krav fremad til de opgaver, den kode og de tests, der skulle opfylde det, og baglæns fra en test eller en kodeændring til det krav, den hører til. I en IT-tvist er sporbarheden ofte den mest direkte vej til at svare på, om et bestemt krav blev implementeret og testet, og hvornår. Men en sporbarhedsmatrix viser kun, at der findes en kobling. Den viser ikke, at kravet er opfyldt.

Artiklen handler om, hvordan sporbarheden sikres, rekonstrueres og efterprøves. Selve vurderingen af afvigelser mod kravene er beskrevet i teknisk mangelsvurdering af software.

Kæden

En fuld kæde har typisk disse led:

Kravet i kravspecifikationen med et entydigt id og en version.
Opgaven: en user story, et work item eller en ticket, der henviser til kravet.
Koden: commits, grene og pull requests, der henviser til opgaven.
Bygget: den pipeline-kørsel, der byggede koden.
Testen: testcases, der er knyttet til kravet, og deres resultater mod et bestemt byg.
Udrulningen: hvilket miljø den testede version kom ud i.

Fremadrettet sporbarhed viser, om alle krav er dækket. Baglæns sporbarhed viser, om der er kode og tests uden noget krav bag, fx ekstraarbejde eller funktioner, der ikke var bestilt. Begge retninger er relevante i en tvist om omfang og tillægsarbejde.

Hvor koblingerne ligger

Azure DevOps kan knytte work items til grene, commits, pull requests, byg og udgivelser med egne linktyper, fx Branch, Commit, Pull Request, Found in build og Integrated in build. Testcases kan knyttes til krav via kravbaserede testsuiter i Azure Test Plans, og automatiserede testresultater fra en pipeline kan kobles til et krav-work item. Widgetten Requirements quality viser beståelsesprocent pr. krav og krav uden tilknyttede tests. Koblingerne er en del af work item’ets historik, så det kan ses, hvornår en kobling blev tilføjet eller fjernet.

Jira viser grene, commits, pull requests, byg og udrulninger fra tilsluttede udviklingsværktøjer, når de refererer til sagens nøgle, fx PROJ-123 i commit-beskeden eller i grenens navn. Koblingen opstår altså ved, at udvikleren skriver nøglen, og ikke ved en formel relation. Testcases håndteres ofte i tilføjelser fra Atlassian Marketplace, som hver har sin egen datamodel og sit eget eksportformat.

Uden for værktøjerne findes sporbarheden ofte som et regneark eller en matrix i et dokument. Den er nem at læse, men har sjældent historik og kan være udfyldt bagefter.

Rekonstruktion, når sporbarheden ikke er vedligeholdt

I mange projekter er koblingerne mangelfulde. Sporbarheden kan så rekonstrueres fra de spor, der findes:

Nøgler i tekst: søg efter krav-id’er og ticket-nøgler i commit-beskeder, grennavne, pull request-titler, testnavne og kodekommentarer.
Tidsmæssig nærhed: commits i perioden, hvor en ticket var i gang, af den udvikler, der var tildelt den. Det er en svagere kobling og skal angives som sådan.
Indhold: tests, hvis navn eller indhold tydeligt svarer til et krav.
Release notes og leverancebeskrivelser, der opregner, hvilke krav en udgivelse dækker.

Hver rekonstrueret kobling bør markeres med sin type, så det fremgår, hvilke koblinger der var registreret i systemet, og hvilke den sagkyndige har udledt. En matrix, der blander de to uden at skelne, kan ikke efterprøves.

Versionsproblemet

Krav ændrer sig. Et krav med samme id kan have haft tre formuleringer i projektets løb, og en test kan være skrevet mod den første. Sporbarheden skal derfor kobles til kravets version på det tidspunkt, testen blev skrevet eller kørt. Kravdokumenter i en wiki har sidehistorik, se sidehistorik og kravændringer, og work items har revisioner, se ticket-systemer: ændringshistorik.

Det samme gælder testcases. En testcase, der bestod ved leverancen, kan være ændret efter en indsigelse. Hent derfor testcasens historik, ikke kun dens nuværende trin.

Sikring

Eksportér kravene med id, version og ændringshistorik.
Eksportér work items med relationer og revisionshistorik via API, ikke kun som en visning på skærmen.
Sikr repositoriet med fuld historik, så commit-beskeder og grene er med.
Sikr testplaner, testcases og testkørsler med resultater og koblingen til byg.
Gem eventuelle matricer i deres oprindelige format med metadata.
Hash alle eksporter, og registrér værktøj, version, konto og tidspunkt.

Hvordan testresultater og byggelogs sikres, er beskrevet i CI/CD-logs og testdokumentation.

Analysen

En sporbarhedsanalyse i en tvist besvarer typisk tre spørgsmål:

Dækning: hvilke krav har mindst én tilknyttet test, og hvilke har ingen?
Resultat: hvad var seneste testresultat for hvert krav mod den version, der blev leveret?
Tidspunkt: hvornår blev kravet første gang implementeret og testet med positivt resultat?

Svarene præsenteres bedst som en matrix med ét krav pr. række og kolonner for opgave, commits, test og resultat, hver med henvisning til kilden. Krav uden kobling og koblinger uden krav listes for sig.

Når parterne har hver sin matrix

Det sker, at kunden og leverandøren hver har ført deres egen oversigt over krav og test, med forskellige id’er, opdelinger og statusværdier. Før de kan sammenlignes, skal der laves en nøgle mellem de to, krav for krav, og den nøgle skal selv dokumenteres. Uoverensstemmelser mellem matricerne er ofte netop dér, uenigheden ligger, og de bør listes særskilt frem for at blive udjævnet.

Typiske fejl i fortolkningen

Dækning læses som opfyldelse. At et krav har en bestået test, viser kun, at testen bestod. Testen kan være for snæver.
Én test for mange krav. En bred ende-til-ende-test knyttet til ti krav siger lidt om hvert af dem.
Koblinger tilføjet bagefter. Er mange koblinger oprettet kort før en milepæl eller efter en tvist er opstået, bør det fremgå. Revisionshistorikken viser det.
Forkert gren. Commits med den rigtige nøgle kan ligge på en gren, der aldrig blev flettet ind i den leverede version.
Krav-id’er genbrugt på tværs af dokumentversioner med forskelligt indhold.

Hvad sporbarheden kan og ikke kan bevise

Registrerede koblinger med historik kan vise, at et krav var knyttet til bestemte opgaver, kodeændringer og tests på et bestemt tidspunkt, og hvilket resultat testene gav mod en bestemt version. Rekonstruerede koblinger kan sandsynliggøre det samme med lavere sikkerhed. Ingen af delene viser alene, at kravet er opfyldt som aftalt. Det kræver en faglig vurdering af testenes indhold og af softwarens faktiske adfærd. Den juridiske side af dokumentationen i en leverancesag er samlet i tjeklisten til IT-leverancesager, og den brede introduktion findes i tvister om IT-projekter.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Teknisk mangelsvurdering af software: metode for den sagkyndige · Testdata, testrapporter og testmiljøer som bevis i IT-tvister

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik