Fase 3.4

Kravspecifikation – Funktionelleog ikke-funktionelle krav

3.1
Udbud eller indkøb?
3.2
Udbudsmateriale
3.3
Datakilder
3.4
Kravspecifikation – Funktionelleog ikke -funktionelle krav
3.5
Kravspecifikation – Sensordata
3.6
Kravspecifikation – Bæredygtighed
3.7
Kravspecifikation- Persondatasikkerhedm.v.
3.8
Interoperabilitet
3.9
Krav til IT-arkitektur
3.10
Udviklingsmetode og proces
3.11
Datavalidering
3.12
Datalagring og deling
3.13
Refleksion og næste skridt
Nulstil tidslinje

Det er vigtigt, at I internt opnår en fælles forståelse af, hvilke funktionelle og ikke-funktionelle krav og ønsker I har til jeres løsning. På den måde får leverandørerne et klart billede af, hvad I som minimum forventer.

  • Funktionelle krav dækker de funktioner, løsningen skal kunne håndtere.
  • Ikke-funktionelle krav beskriver, hvordan systemet skal yde – f.eks. i forhold til design og arkitektur, brugervenlighed, sikkerhed m.v.

Overvej bl.a.:

  • Hvilke krav og ønsker I har til løsningens funktionalitet?
  • Hvilke integrationer er nødvendige?
  • Hvordan skal data behandles og opbevares?

Formulér helst de funktionelle krav som en beskrivelse af behov og ønsket funktionalitet fremfor at angive konkrete løsningsmåder (for eksempel brug af drop down-felter). For detaljerede anvisninger kan hæmme innovation og begrænse leverandørens muligheder for at finde den bedst egnede løsning.

 

De ufravigelige krav som for eksempel dataejerskab, GDPR og it-sikkerhed skal gerne stilles som et ”skal-krav”/mindstekrav. Se også punkt 3.7 og 3.9: Kravspecifikation sikkerhed og arkitektur.

 

Vigtige datafokusområder:

  • Datakontekst: I hvilken kontekst skal data bruges? Dette definerer kravene til de data, I indsamler. Er der tale om kritiske data med behov for realtidsopdateringer eller historiske data med for eksempel ugentlige batchopdateringer? Er der andre systemer, der er afhængige af jeres data? Kan der være tale om følsomme persondata eller data om kritisk infrastruktur?
  • Datakvalitet: Beskriv kravene til både rådata og metadata, så det er tydeligt hvilke data I ønsker. Læn jer gerne op ad standarder.
  • Brugsret og ejerskab: Stil krav om, at de data, løsningen indsamler og genererer, deles løbende i det format, kommunen bestemmer. Kommunen skal også have ret til at genbruge og dele data i flere sammenhænge. Også relevant i forhold til en exitstrategi i forbindelse med leverandørskift.
  • Dataudveksling: Stil krav om API'er til nem integration med andre løsninger.
  • Undgå leverandørbindinger: Stil krav om brug af åbne standarder, at data er dokumenteret og kan trækkes ud af IT-løsningen på et senere tidspunkt.
    I EU er der udviklet nogle minimumskrav om interoperabilitet (MIMs), så deling af data og skalerbarhed bliver lettere (se også punkt 3.8: Interoperabilitet).
  • Sikkerhed og standarder: Se punkt 3.7: Personsikkerhed m.v.

Handling

  • Afklar i hvilken kontekst data indsamles, og hvordan data også fra denne løsning skal bruges?
  • Beskriv løsningen.
  • Identificer hvilke ønsker og krav I vil stille til løsningen. Funktionelle og ikke-funktionelle.
  • Hvilke af disse krav er ufravigelige?
  • Skriv dem ind i skabelonen, der ligger under Værktøj.

Værktøjer