Fas 3.4
Kravspecifikation – Funktionella och icke-funktionella krav
3.1
Anbud eller upphandling?
Anbud eller upphandling?
3.2
Förfrågningsunderlag
Förfrågningsunderlag
3.3
Källor
Källor
3.4
Kravspecifikation –Funktionella och icke-funktionella krav
Kravspecifikation –Funktionella och icke-funktionella krav
3.5
Kravspecifikation – Sensordata
Kravspecifikation – Sensordata
3.6
Kravspecifikation – Hållbarhet
Kravspecifikation – Hållbarhet
3.7
Kravspecifikation –Personuppgiftssäkerhet m.m.
Kravspecifikation –Personuppgiftssäkerhet m.m.
3.8
Interoperabilitet
Interoperabilitet
3.9
Krav på IT-arkitektur
Krav på IT-arkitektur
3.10
Utvecklingsmetod och process
Utvecklingsmetod och process
3.11
Validering av personuppgifter
Validering av personuppgifter
3.12
Lagring och delning av uppgifter
Lagring och delning av uppgifter
3.13
Reflektion och nästa steg
Reflektion och nästa steg
Nulstil tidslinje
Det är viktigt att ni internt uppnår en gemensam förståelse för vilka funktionella och icke-funktionella krav och önskemål ni har på lösningen. På så sätt får leverantörerna en tydlig bild av vad du förväntar dig som ett minimum.
- Funktionskrav omfattar de funktioner som lösningen ska kunna hantera.
- Icke-funktionella krav beskriver hur systemet ska prestera – t.ex. i förhållande till design och arkitektur, användarvänlighet, säkerhet etc.
Tänk bland annat på följande:
- Vilka krav och önskemål har ni på lösningens funktionalitet?
- Vilka integrationer behövs?
- Hur ska data behandlas och lagras?
Formulera helst funktionskraven som en beskrivning av behov och önskad funktionalitet snarare än att specificera specifika lösningar. För detaljerade instruktioner kan hämma innovationen och begränsa leverantörens förmåga att hitta den lämpligaste lösningen.
De obligatoriska kraven som dataägande, GDPR och IT-säkerhet bör helst sättas som ett "måste-krav"/ minimikrav. Se även avsnitt 3.7 och 3.9 Kravspecifikation, säkerhet och arkitektur.
Fokusområden för nyckeldata:
- Datakontext: I vilket sammanhang ska data användas? Detta definierar kraven för de data du samlar in. Är det kritisk data som behöver uppdateras i realtid eller historiska data med till exempel veckovisa batchuppdateringar? Finns det andra system som är beroende av din data? Kan det vara känsliga personuppgifter eller data om kritisk infrastruktur?
- Datakvalitet: Beskriv kraven på båderådata och metadata, så att det är tydligt vilka data du vill ha. Känn dig fri att luta dig mot standarder.
- Nyttjanderätt och äganderätt: Kräv nyttjanderätt/äganderätt för de data som lösningen samlar in och genererar delas löpande idet format som kommunen bestämmer. Kommunen måste också ha rätt att återanvända och dela data i flera sammanhang. Även relevant i relation till en exit strategi i samband med ett byte av leverantör.
- Datautbyte: Kräv API:er för enkel integration med andra lösningar.
- Undvik leverantörsinlåsningar: Kräv användning av öppna standarder, att data dokumenteras och kan extraheras från IT-lösningen vid ett senare tillfälle.
I EU har vissa minimikrav på interoperabilitet tagits framför att underlätta datadelning och skalbarhet (se även punkt 3.8 Interoperabilitet). - Säkerhet och standarder: Se punkt 3.7.
Hur går man tillväga
- Förtydliga i vilket sammanhang data samlas in och hur data från denna lösning också kommer att användas?
- Beskriv lösningen.
- Identifiera vilka önskemål och krav ni kommer att ha på lösningen. Funktionella och icke-funktionella.
- Vilka av dessa krav är obligatoriska?
- Lägg in dem i mallen som finns under ”Verktyg”.