Hvilke kilder kan dokumentere softwarekrav og funktioner?

Kort svar: Hvilke kilder kan dokumentere softwarekrav og funktioner?

Der findes ingen enkelt kilde, der dækker alle krav til et softwaresystem. Dokumentationen bygger i praksis på fem typer materiale med meget forskellig status: standarder, offentligretlige krav til it-systemer, databeskyttelsesmateriale, kommunale dokumentationskrav samt udbuds- og aftalemateriale.

Standarder udgives af Dansk Standard og af internationale organer som CEN og ISO. DS/ISO/IEC 25010 findes fx i en 2011- og en 2023-udgave med titler om kvalitetskrav og evaluering på system- og softwareområdet.

Offentligretlige krav til it-systemer beskrives i Folketingets Ombudsmands myndighedsguide. Her fremgår det, at de generelle forvaltningsretlige regler og principper gælder, uanset om sagsbehandlingen er manuel eller digital.

Databeskyttelsesdelen dækkes dels af KL's kommunale anbefalinger til at opfylde databeskyttelsesforordningens dokumentationskrav, dels af Datatilsynets katalog over foranstaltninger, herunder »Sikkerhedsmæssig styring og vedligehold af software«.

Kommunale dokumentationskrav optræder typisk i udbud, samarbejdsaftaler og dialog med kommunerne og kaldes samlet »KKR-krav«. Der findes dog ikke én national KKR-standard for journalsystemer og heller ikke en officiel godkendelsesordning, hvor et journalsystem kan blive »KKR-godkendt«.

Kilderne må derfor ikke behandles ens: Nogle er bindende retsregler, nogle er konsensusbaserede standarder, nogle er kommunernes egne anbefalinger. Andre fastlægger slet ikke konkrete softwarefunktioner, men kun hvilken dokumentation leverandøren skal kunne fremlægge.

Sammenligning af kilder til dokumentation af softwarekrav og funktioner

Hovedkilder til dokumentation af softwarekrav i danske myndigheder

Standarder som dokumentationsgrundlag: DS/ISO/IEC 25010 og standarders rolle

Dansk Standard definerer en standard som »Dokument til fælles og gentagen anvendelse, der giver regler, retningslinjer eller karakteristiske træk ved aktiviteter eller ved resultaterne af disse. Dokumentet er fastlagt ved konsensus og vedtaget af et anerkendt organ. Hensigten er at opnå optimal orden i en given sammenhæng.«

Definitionen gengives af DANAK, der bruger standarder som grundlag for akkreditering. En standard kan være udarbejdet af det nationale standardiseringsorgan – i Danmark Dansk Standard – eller komme fra internationale sammenslutninger af standardiseringsorganer: CEN i Europa og ISO globalt.

Præfikserne viser, hvor dokumentet kommer fra: DS står for dansk godkendte standarder, EN for europæisk godkendte standarder, og ISO eller IEC for internationale standarder. DS/EN ISO/IEC 17025 er fx en international (ISO/IEC) og europæisk (EN) standard, der er dansk godkendt (DS).

Bliver en standard brugt som kilde i en kravspecifikation, bør den citeres med fuld betegnelse. Det gør det entydigt, hvilket dokument der henvises til.

DS/ISO/IEC 25010 findes i to danske udgaver med forskelligt sigte. DS/ISO/IEC 25010:2011 har titlen »System og softwareudvikling – Kvalitetskrav til og evaluering af systemer og software (SQuaRE) – Kvalitetsmodeller vedrørende systemer og software«. DS/ISO/IEC 25010:2023 har titlen »System- og softwareudvikling – Kvalitetskrav til og evaluering af systemer og softwareprodukter (SQuaRE) – Produktkvalitetsmodel«.

Den internationale pendant ISO/IEC 25010:2011 har titlen »Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models«. Versionerne har altså ikke samme genstand: 2011-udgaven beskriver kvalitetsmodeller vedrørende systemer og software, mens 2023-udgaven er en produktkvalitetsmodel.

Konsekvensen for dokumentationen er konkret: Angiv altid standardkode og årgang, når et krav støttes på en standard. Et systemspecifikt krav kan henvise til den ene udgave og ikke den anden.

Standarderne findes via Dansk Standards webshop, hvor versionshistorikken for den enkelte standard også fremgår. En standard fastlægger fælles regler, vejledning eller kendetegn ved aktiviteter eller resultater. Den beskriver ikke en bestemt leverandørs funktioner. Den kan derfor kun danne grundlag for et krav, hvis kravet formuleres, så det kan verificeres mod det konkrete system.

Offentlige it-systemer: Ombudsmandens forvaltningsretlige krav

Folketingets Ombudsmands myndighedsguide, afsnit 13 om generelle forvaltningsretlige krav til offentlige it-systemer, beskriver kravene til sagsstyringssystemer og selvbetjeningsløsninger. Ifølge guiden kan det være en udfordring at sikre, at offentlige it-systemer – herunder sagsstyringssystemer og selvbetjeningsløsninger – lever op til grundlæggende forvaltningsretlige krav.

Kravene til myndighedernes sagsbehandling gælder i lige så høj grad, når sagsbehandlingen digitaliseres og automatiseres. De generelle forvaltningsretlige regler og principper gælder, uanset om sagsbehandlingen foregår manuelt eller digitalt.

Et it-system skal understøtte og sikre journalisering og dokumentation af relevante sagsakter. Det skal også sikre et afsendt brevs integritet og autenticitet, herunder entydig identifikation af afsenderen.

Ansvaret for at kravene efterleves ligger hos den enkelte myndighed – ikke hos leverandøren.

Ombudsmanden har i de senere år i en del sager konstateret, at offentlige it-løsninger ikke har sikret overholdelse af de forvaltningsretlige krav. Guiden peger på, at dårlig forberedelse og tidsoptimisme kan føre til fejl og mangler ved it-systemerne, som kan få store konsekvenser for borgernes retssikkerhed.

Fejlene rammer typisk ikke kun én borger: Skadevirkningerne mangedobles, fordi manglerne slår systematisk igennem, indtil de udbedres. Når et mangelfuldt it-system først er sat i drift, kan det både være svært og dyrt at rette op på.

På baggrund af sine undersøgelser har Ombudsmanden opstillet generelle læresætninger til myndighederne, når de udvikler og idriftsætter nye systemer. En forsvarlig tilrettelæggelse forudsætter blandt andet, at både formelle og materielle krav til sagsbehandlingen indtænkes og overholdes i de forløb, sagerne kan tænkes at få.

Materialet henviser til artiklen »Gode it-systemer kræver god forberedelse« i FOB 2023 og er senest opdateret 7. september 2026. For en kravspecifikation er guiden dermed kilden til de funktionelle krav om journalisering, dokumentation af sagsakter, brevets integritet og autenticitet samt entydig afsenderidentifikation.

Databeskyttelse: KL’s dokumentationsanbefalinger og Datatilsynets tiltag for software

KL's videncenter har siden »Databeskyttelsesforordningens dokumentationskrav« med anbefalinger til at opfylde forordningens dokumentationskrav. Baggrunden er, at der blev efterspurgt vejledning om, hvordan kommunerne lever op til påvisnings- og dokumentationskravene uden at over- eller underimplementere dem.

Dengang forelå der ikke officiel vejledning fra Datatilsynet om emnet, og GDPR-bestemmelserne giver ikke i sig selv megen hjælp til dokumentationsniveauet. Partnerskabskommunerne har derfor udarbejdet kommunernes bedste bud på, hvad der skal til.

Anbefalingerne har været forelagt Datatilsynet, som afgav bemærkninger, der er indarbejdet. Fordi der endnu ikke er tilstrækkelig praksis om dokumentationskravene, har tilsynet dog ikke kunnet vejlede generelt om dem.

Anbefalingerne er derfor kommunernes bedste bud på minimumsniveauet for at leve op til påvisningskravene i databeskyttelsesforordningens artikel 5, stk. 2, og artikel 24. Selve dokumentet hedder »Databeskyttelsesforordningens dokumentationskrav – kommunale anbefalinger« og offentliggøres som PDF på KL's side.

Kilden dokumenterer altså et dokumentationsniveau, ikke et bestemt sæt softwarefunktioner. Den enkelte myndighed må selv oversætte det til krav til sit system og sin behandlingsoversigt.

Datatilsynets katalog over foranstaltninger indeholder »Sikkerhedsmæssig styring og vedligehold af software«, senest opdateret 28.05.25. Kataloget beskriver, hvilke risici der adresseres, og hvilke tiltag der kan overvejes.

Software forstås bredt: operativsystemer som Microsoft Windows, egenudviklet software, tredjepartssoftware som Microsoft Word og Adobe Acrobat samt firmware – i pc, smartphone, server og netværksudstyr som router og firewall og i IoT-enheder som overvågningskamera, plejerobot, medicinsk udstyr, sensor og meget andet.

Beskyttelse mod ondsindet udnyttelse forudsætter, at softwaren vedligeholdes sikkerhedsmæssigt. Man skal undgå, begrænse eller isolere den mest muligt, fordi udnyttelse af en sårbarhed eller et svagt log-in i én enhed kan give mulighed for at kompromittere andre enheder på samme netværk.

Ved indkøb af enheder, der skal kobles på organisationens netværk, peger kataloget på konkrete forhold, som kan omsættes til krav. Leverandøren skal levere sikkerhedsopdateringer til softwaren, og det skal være tydeligt, hvordan opdateringen foregår.

Unødvendige funktioner og porte skal kunne slås fra, lukkes eller fjernes. Alle adgangskoder skal kunne ændres til noget selvvalgt. Kommunikation til og fra enheden skal kunne foregå forsvarligt krypteret.

Leverandøren skal oplyse, hvornår der ikke længere laves sikkerhedsmæssig patch eller opdatering af softwaren, og hvornår softwaren ikke længere kan købes eller supporteres.

Hertil kommer driftstiltag: Netværket opsættes til kun at acceptere kendte, godkendte enheder, hvis software kan holdes sikkerhedsmæssigt opdateret. Software og firmware holdes opdateret. Standard-login ændres eller fjernes, før udstyr sættes på nettet.

Alle log-in har stærke passwords på minimum 15 karakterer og beskyttelse imod brute-force-angreb, og der anvendes eventuelt flerfaktorautentifikation. Samtidig begrænses muligheden for administrering og fjernstyring af enheder, så funktionaliteten så vidt muligt ikke er tilgængelig direkte fra internettet, men kun »on-site«.

Kommunale dokumentationskrav på socialområdet: KKR-guidelines og deres grænser

Når en kommune køber en social indsats hos et privat eller selvejende tilbud, følger der næsten altid krav til dokumentation og opfølgning med. I udbud, samarbejdsaftaler og dialog med kommunerne kaldes disse krav nogle gange samlet »KKR-krav«.

Begrebet kan være misvisende: Der findes ikke én national KKR-standard for journalsystemer og heller ikke en officiel godkendelsesordning, hvor et journalsystem kan blive »KKR-godkendt«.

KKR – Kommunekontaktrådene – er en del af KL's politiske organisation og består af fem: Nordjylland, Midtjylland, Syddanmark, Sjælland og Hovedstaden. De koordinerer blandt andet kommunernes samarbejde på socialområdet.

For et socialt tilbud er det derfor ikke afgørende, om journalsystemet har et bestemt KKR-stempel. Det afgørende er, om tilbuddet kan dokumentere den indsats, kommunen har bestilt, følge udviklingen hos borgeren og levere den nødvendige dokumentation, når kommunen beder om den.

Et aktuelt eksempel på mere ensartet dokumentation er KKR Sjælland. Her tilsluttede kommunerne sig i juni 2026 fem fælleskommunale guidelines for socialfaglige indkøb og kontraktstyring på det specialiserede socialområde.

En af de fem handler direkte om dokumentation. Her fastslår kommunerne, at de vil stille klare og ensartede krav til leverandørernes dokumentation af både de ydelser, der faktisk er leveret, og den ønskede effekt for borgeren.

Formålet er blandt andet at skabe et fælles grundlag for opfølgning og for eventuel justering af indsatsen, hvis borgerens behov ændrer sig.

Det er samtidig vigtigt at forstå, hvad guidelines ikke siger. De fastlægger ikke, hvilket journalsystem tilbuddet skal bruge, og stiller ikke tekniske krav om bestemte databaser, integrationer, eksportformater eller softwarefunktioner.

Kravet handler om resultatet af dokumentationen – ikke om hvilket it-system der producerer den. For et journalsystem betyder det, at systemet bør kunne skabe en tydelig sammenhæng mellem kommunens bestilling, borgerens mål, den leverede indsats, udviklingen og opfølgningen.

Hvis sammenhængen kun kan findes ved manuelt at gennemgå journalnotater, mails, Word-dokumenter og regneark, bliver både statusarbejde og myndighedsopfølgning unødigt tungt.

Fra kilde til kravspecifikation: Sådan bruger du kilderne konkret

Start med at klassificere kilden, fordi klassifikationen bestemmer, hvor tungt kravet vejer. Forvaltningsretlige krav fra Ombudsmandens myndighedsguide og reglerne i databeskyttelsesforordningen er bindende, og myndigheden bærer ansvaret for, at de efterleves.

Standarder er konsensusbaserede dokumenter med normer, anvisninger eller kendetegn. KL's anbefalinger er kommunernes bedste bud på minimumsniveauet for påvisningskravene i artikel 5, stk. 2, og artikel 24, mens KKR Sjællands guidelines er krav til dokumentationens resultat – ikke til systemets tekniske udformning.

Giv hvert krav en entydig henvisning til kilden, så det kan spores. Ved standardkrav: standardkode med årgang og eventuelt afsnit, fx DS/ISO/IEC 25010:2011 eller DS/ISO/IEC 25010:2023.

Ved krav fra Ombudsmandens myndighedsguide: angiv afsnittet. Ved databeskyttelseskrav: angiv artikelnummer. Ved sikkerhedsforanstaltninger: angiv det konkrete punkt i Datatilsynets katalog over foranstaltninger. Ved kontraktuelle krav: angiv den konkrete aftale eller det konkrete udbudsdokument.

Uden henvisningen kan kravet ikke forsvares senere. Man kan heller ikke afgøre, om det er ændret, fx ved en ny udgave af standarden.

Formulér kravet, så det kan verificeres mod det leverede system. Et krav skal kunne besvares med ja eller nej ud fra en test, en konfigurationsgennemgang eller et dokument fra leverandøren.

»Systemet understøtter journalisering og dokumentation af relevante sagsakter« og »systemet sikrer et afsendt brevs integritet og autenticitet, herunder entydig identifikation af afsenderen« er eksempler på funktionelle krav, der kan spores til Ombudsmandens myndighedsguide.

»Alle log-in har stærke passwords på minimum 15 karakterer og beskyttelse imod brute-force-angreb«, »kommunikation til og fra enheden kan foregå forsvarligt krypteret« og »software holdes sikkerhedsmæssigt opdateret« er ikke-funktionelle krav, der kan spores til Datatilsynets katalog.

Krav om, at leverandøren oplyser, hvornår der ikke længere laves sikkerhedsmæssig patch eller opdatering, og hvornår softwaren ikke længere kan købes eller supporteres, hører hjemme i udbuds- og aftalematerialet. Der kan det gøres til en løbende oplysningsforpligtelse.

Hold til sidst de to slags kilder ad, når kravene skrives ind. Kilder som standarder, forvaltningsretlige krav og databeskyttelseskrav kan føre til konkrete krav til systemets funktioner og egenskaber.

Kilder som KKR Sjællands guidelines fører til dokumentationskrav – hvad leverandøren skal kunne dokumentere om leverede ydelser og effekt for borgeren. De bør derfor formuleres som krav til dokumentationens indhold og opfølgning, ikke som krav om bestemte databaser, integrationer, eksportformater eller softwarefunktioner, som guidelines ikke fastlægger.

Sådan omsætter du kilder til konkret kravspecifikation