Forside · Gennemgået oktober 2026 · Af John Nielsen
I mange IT-projekter ligger kravspecifikationen ikke i ét underskrevet dokument, men i en wiki som Confluence, i delte Word-dokumenter eller i backlog-elementer. Tvisten handler så om, hvilken version af et krav der gjaldt på et bestemt tidspunkt, og hvem der ændrede det. Wikiens sidehistorik gemmer typisk hver gemt version med forfatter og tidspunkt, og den kan i de fleste tilfælde rekonstruere kravets udvikling. Men historikken har huller, især når sider bruger dynamisk indhold, og en eksport til PDF fjerner den helt.
Den juridiske side af tvister om IT-projekter og skønsmandens rolle er beskrevet i IT-skøn i tvister om IT-projekter og software. Her handler det om de tekniske kilder.
Hvad sidehistorikken indeholder
En wikiside i Confluence og lignende systemer gemmes som en række versioner. For hver version registreres typisk:
- versionsnummer,
- forfatteren af ændringen,
- tidspunktet,
- en eventuel ændringskommentar,
- selve indholdet i systemets lagringsformat.
Ud fra to versioner kan systemet vise en sammenligning. Derudover findes kommentarer, både på siden og knyttet til bestemte tekststeder, vedhæftninger med egne versioner, sidebegrænsninger og mærkater. Systemets auditlog registrerer administrative hændelser som ændring af rettigheder, sletning og gendannelse af sider. Hvilke hændelser der kommer med, og hvor længe de gemmes, afhænger af abonnement og administratorens indstillinger, så kontrollér det i den konkrete instans.
Faldgrube: dynamisk indhold
Den vigtigste tekniske faldgrube er, at en wikiside ikke altid viser sit eget indhold. Makroer kan hente indhold andre steder fra, når siden vises:
- En inkluderingsmakro viser indholdet af en anden side. Ændres den anden side, ændres visningen uden en ny version af den første.
- En Jira-makro viser sager fra Jira med deres aktuelle status og felter. Den gemte version indeholder kun forespørgslen, ikke resultatet.
- Skabeloner og fælles tekstblokke kan være opdateret centralt.
- Vedhæftninger, fx et regneark med krav, kan have fået nye versioner, mens siden selv er uændret.
Sidehistorikken viser derfor præcist, hvad der stod i sidens egen kildetekst, men ikke nødvendigvis, hvad en læser så på et givent tidspunkt. For hvert krav, der er vigtigt for sagen, skal det kontrolleres, om det står direkte på siden eller hentes fra en anden kilde. I sidstnævnte tilfælde skal den anden kildes historik også hentes. Ændringshistorikken for Jira-sager er behandlet i Ticket-systemer: ændringshistorik.
Mindre ændringer og notifikationer
Mange wikier har en mulighed for at markere en ændring som mindre, så følgere ikke får besked. Ændringen gemmes stadig som en version, men den kan være gået upåagtet hen. I en tvist kan det være relevant at vise, hvem der blev underrettet om en ændring. Det kræver adgang til notifikationsindstillinger eller mails, ikke kun sidehistorikken.
Udtræk
Via API
Confluence og de fleste andre wikier har et API, hvorfra alle versioner af en side kan hentes med metadata og indhold i lagringsformatet. Det giver det mest fuldstændige udtræk. Hent for hver relevant side alle versioner, kommentarer, vedhæftninger med versioner og sidens placering i hierarkiet. Hent desuden brugerlisten, så konto-id’er kan oversættes til navne.
Eksport af området
En samlet eksport af et wikiområde i systemets eget format kan indeholde historikken, men kan kun læses fuldt i det samme system. I Confluence Data Center indeholder XML-eksporten af et område også tidligere sideversioner. I Confluence Cloud er XML-eksporten først og fremmest beregnet til flytning til en anden installation, og det bør kontrolleres i den konkrete eksportfil, om historikken er med. PDF- og Word-eksporter indeholder kun den aktuelle version og den gengivne visning.
Præsentation
Til rapporten kan relevante versioner gengives, og ændringer mellem dem vises side om side. Hver gengivelse bør henvise til versionsnummer og tidspunkt i de rå data. Beregn hashværdier af udtrækket, og lav et manifest. Se Hashmanifest for filsamlinger.
Kravdokumenter uden for wikien
Krav ligger også andre steder, med andre former for historik:
- Word-dokumenter i SharePoint eller OneDrive har versionshistorik med forfatter og tidspunkt, og auditloggen kan vise redigeringer. Se SharePoint og OneDrive: versionshistorik og delingslinks.
- Kravdokumenter i et kodelager, fx i Markdown, har Git-historik med commits, forfattere og tidspunkter. Se Git og kildekode som bevis.
- Backlog-elementer i Jira eller Azure DevOps har feltændringslog som andre sager.
- Mails med vedhæftede versioner kan være det eneste sted, hvor den version, der faktisk blev sendt til kunden, er bevaret.
Den samme kravtekst kan findes i flere af disse kilder i forskellige versioner. En samlet tidslinje over kravets udvikling på tværs af kilderne er ofte mere oplysende end historikken i én kilde.
Fortolkning
Forfatter er en konto. Historikken viser den konto, der gemte versionen. Ved delte konti eller integrationer, der skriver på vegne af andre, er forfatteren ikke nødvendigvis den person, der formulerede teksten.
Samtidig redigering. Nyere wikier tillader flere samtidige redaktører. Versionen kan da tilskrives den, der udløste gemningen, mens andre har bidraget. Kontrollér, om systemet registrerer bidragydere ud over forfatteren.
Tidszoner. Brugergrænsefladen viser lokal tid for den enkelte bruger, API’et typisk UTC. Når en ændring ligger tæt på et møde eller en deadline, kan en times forskel afgøre, om ændringen kom før eller efter. Angiv derfor altid tidszonen.
Gendannede versioner. Hvis en ældre version gendannes, oprettes en ny version med det gamle indhold. Det kan ligne en ny ændring, men er en tilbagerulning.
Slettede sider. Slettede sider kan ligge i områdets papirkurv i en periode og gendannes med historik. Er papirkurven tømt, kan siden være væk, men sletningen kan fremgå af auditloggen.
Hvilken version gjaldt?
Det centrale spørgsmål er ofte, hvilken version af et krav der var gældende ved en bestemt milepæl: kontraktindgåelse, godkendelse af en designfase eller overlevering. Teknisk løses det ved at finde de versioner, der var de seneste før hvert af disse tidspunkter, og ved at kontrollere, om der findes en eksplicit markering af en godkendt version, fx en mærkat, et versionsnummer i titlen, en kopi i et arkivområde eller en mail med en PDF-udgave.
Findes der en PDF-udgave, der blev sendt eller underskrevet, kan den sammenlignes med wikiens version fra samme tidspunkt. Er den underskrevet via en e-signaturløsning, kan løsningens audit trail datere underskriften, se Audit trail i e-signaturløsninger. Stemmer de overens, styrker det begge. Afviger de, er det vigtigt at finde ud af hvorfor, fx om PDF’en blev genereret med dynamisk indhold, der senere har ændret sig.
Dokumentation
Rapporten bør angive, hvilke sider og kilder der er udtrukket, med metode, værktøj, tidspunkt og hashværdier. For hvert krav, der er centralt for sagen, vises en tidslinje over versionerne med forfatter, tidspunkt og den konkrete tekstændring, og det angives, om indholdet stod direkte på siden eller blev hentet fra en anden kilde. Huller, fx sider, hvor historikken er begrænset, eller dynamisk indhold, hvis historik ikke kunne fremskaffes, skal fremgå tydeligt.
Hvad historikken kan bevise
Sidehistorikken kan vise, hvad der stod i sidens egen tekst ved hver version, og hvilken konto der gemte den. Kombineret med aftaler, mødereferater og mails kan den vise, hvilken version der var gældende ved en milepæl. Den kan ikke i sig selv vise, at en ændring var aftalt, eller at modparten havde set den. Hvordan virksomheden selv dokumenterer et IT-projekt løbende, er beskrevet i Leverandøren leverer ikke.
Kilder og versioner
- Atlassian: eksport af et område i Confluence Cloud
- Atlassian: XML-eksportens entities.xml i Confluence Data Center
- Atlassian: Confluence Cloud REST API, sideversioner
Senest gennemgået: oktober 2026.
Næste skridt
- GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens
- Massesletning efter en tvist er opstået: tekniske tegn
Læs også: Ticket-systemer: ændringshistorik i Jira, ServiceNow og lignende · SLA-målinger: hvordan tallene beregnes, og hvor de kan være forkerte
→ Uvildig IT-sagkyndig med forensic-baggrund · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
