Fase 3.4
Kravspecifikation – Funktionelleog ikke-funktionelle krav
3.1
Udbud eller indkøb?
Udbud eller indkøb?
3.2
Udbudsmateriale
Udbudsmateriale
3.3
Datakilder
Datakilder
3.4
Kravspecifikation – Funktionelleog ikke -funktionelle krav
Kravspecifikation – Funktionelleog ikke -funktionelle krav
3.5
Kravspecifikation – Sensordata
Kravspecifikation – Sensordata
3.6
Kravspecifikation – Bæredygtighed
Kravspecifikation – Bæredygtighed
3.7
Kravspecifikation- Persondatasikkerhedm.v.
Kravspecifikation- Persondatasikkerhedm.v.
3.8
Interoperabilitet
Interoperabilitet
3.9
Krav til IT-arkitektur
Krav til IT-arkitektur
3.10
Udviklingsmetode og proces
Udviklingsmetode og proces
3.11
Datavalidering
Datavalidering
3.12
Datalagring og deling
Datalagring og deling
3.13
Refleksion og næste skridt
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
Skabelon til krav.
Noter jeres krav til projektet og få et samlet overblik.
KL’s principper for IoT.
Kort overblik over KL’s principper for IoT, ejerskab og økosystemer.
RISEs kortfilm - “Visionen om den smarta staden”.
Om potentialet i smarte byer.
Från data til datadelning i 10 steg. - RISE
Artikel der beskriver datas rejse fra kilde til (gen)anvendelse.