Kravredaktionsmøde den 13. marts 2018

Transkript

1 Kravredaktionsmøde den 13. marts 2018 Tidspunkt: 13. marts 2018 kl :00. Mødested: Mødelokale 8 på Rådhuset, Rådhustorvet 4, Horsens Mødedeltagere: Heidi, Carsten, Thomas, Henrik og Rasmus (OS2) Afbud: Martin Referent: Rasmus Ankomst og velkomst, Vi skal lige ankomme og finde os til rette Formen på dagsorden drøftes kort og der er enighed om at den grundige og velbeskrevne form fungerer godt. Dagsordenpunkt 1, Udvidelse af kravredaktionen, Orientering Velkommen til Heidi Der er udsigt til, at der i fremtiden kan blive brug for flere ressourcer i Kravredaktionen. Derfor kunne det være rart med muligheden for at lave noget af benarbejdet omkring nye krav og funktionalitet ad hoc i smågrupper, og så kan redaktionen konsolidere og lave indstillinger til styregruppen. Heidi Johansen fra Randers kommune har sagt ja til at være med i kravredaktion - velkommen Vi kan indstille nye medlemmer til kravredaktionen til styregruppen Heidi Johansen bydes velkommen i kravredaktionen. Det drøftes kort at det er vigtigt med en tyngde i kravredaktionen da der også kan ske frafald til møder. En juridisk kompetence kunne være være et bud på en kompetence som skal tilføres kravredaktionen på sigt. Holdningen i kravredaktionen er at der ikke skal være for mange. Da det kan dræbe drøftelser og beslutninger. Drøftelsen går også på at gruppen ikke må blive for forsigtige i krav-stillen. Vi må ikke gøre krav ubrugelige. Det besluttes at næste dagsorden skal indeholde et beslutningspunkt om der skal leverandører med i kravredaktionen. Kunne evt. være en bid manager fra en større leverandør. Side: 1

2 Dagsordenpunkt 2, Guide til udfyldelse af krav i OS2kravmotor, samt kommunikation af denne. Beslutning Opfølgning på dagsordenspunkt 5 fra sidste møde Brian har udarbejdet følgende: Overordnet Kravet skal formuleres så det kort og præcist beskriver det krav som stilles til leverandøren. Dvs. at kravet skal falde ind i præcis én kravkategori, og ikke kunne opsplittes i flere selvstændige krav. Retningslinjer Konsistens. Kravteksten skal bruge betegnelsen "kommunen" om den indkøbende kommune, og ikke kommunens navn og/eller andre betegnelser som "kunden", "indkøberen" eller lignende. Konsistens. Kravteksten skal bruge betegnelsen "løsningen" om det it-system der skal indkøbes. Konsistens. Samme ord for tværgående begreber bør bruges i alle krav, fx anvendes GDPR som angivelse for eudatabeskyttelsesforordningen. Det anbefales, at man gør sig bekendt med begreber, der anvendes i eksisterende krav. Ikke-overlappende. Krav bør så vidt muligt ikke overlappe hinanden. System-uafhængigt. Kravteksten skal ikke referere til det ønskede system ved navn, eller til andre systemer ved navn med mindre, der er tale om nationale løsninger. Fx angives 'ESDH-system' i stedet for 'Formpipe Acadre', og 'Kommunens EOJ løsning' i stedet for 'KMD Nexus'. Dette sikrer, at kravteksten kan genbruges af andre kommuner. Nationale løsninger som patientindeks, fælles medicinkort, DFDG m.m. angives ved navns nævnelse. Vurderingsmuligt. Kravet skal formuleres, så leverandørens besvarelse kan vurderes, dvs. kravet skal så vidt muligt formuleres, så man efterfølgende kan holde leverandørens besvarelse op mod kravet. Form Formuleringen af kravteksten bør følge nedenstående opbygning Krav. Kort kravtekst der forklarer, hvad vi ønsker. Rationale. Kort tekst, der angiver vores rationale for at stille kravet. Konsekvens ved afgivelse. Den konsekvens det vil have for os, hvis kravet ikke indfries. Eksempel Løsningen skal understøtte fødereret adgangsstyring. Den fælleskommunale rammearkitekturs byggeblokke for sikkerhed baserer sig på fødereret adgangsstyring, og KOMBITs støttesystemer til samme, er en konkret implementation af denne strategi. Løsningen skal støtte op om denne strategi, ved at understøtte, at brugere oprettes og tildeles rettigheder i kommunens centrale rettighedsstyringssystem, eller ved at rettigheder tildeles via KOMBITs støttesystemer. Løsningen må derfor ikke kræve, at brugere skal oprettes manuelt i løsningen, eller at tildelingen af rettigheder til brugere skal foregå inde i løsningen. Løsningen må dog gerne tilbyde funktionalitet til intern brugerstyring, så længe den også understøtter fødereret brugerstyring. Løsningen skal understøtte SAML 2.0 eller WS-Federation som føderationsteknologi, da dette er kompatibelt med den brugerstyringsløsning, som kommunen anvender, samt den teknologi som KOMBITs støttesystemer anvender. Side: 2

3 Hvis kravet ikke opfyldes, vil det introducere unødige arbejdsgange, og øge omkostningerne til brugerstyring i kommunen. Kravredaktionen godkender teksten. Brian opretter et hjælpeikon ved kravoprettelse. Rasmus er ejer på user story som definerer opgaven. Rasmus opretter også som en vejledning i OS2viden. Det besluttes at der udarbejdes en kort intro tekst om at kravredaktionen på møde d. 13/3 har besluttet ovenstående. Det besluttes at Heidi arrangerer arbejdsgruppe med Carsten. Denne arbejdsgruppe gennemgår de eksisterende krav så de leer op til ovenstående beslutning. Det forventes der kommer udkast til næste møde så dette kan godkendes. Det beslutte at er der krav hvor der rationalet ikke kan findes skal disse op til drøftelse. Dette vil være en sideeffekt af arbejdsgruppens arbejde. Note: Vejledning er efterfølgende oprettet på OS2viden, Dagsordenpunkt 3, Non-funktionelle krav. Beslutning, drøftelse a) Opfølgning fra sidst: Afgrænsning af begrebet non-funktionelt krav (beslutning) Definition på funktionelt krav er: Omfatter funktionalitet som systemet skal stille til rådighed for slutbrugeren. Non-funktionelle krav er derfor: Det fundament som de funktionelle krav påvirker. Alt der ikke umiddelbart har noget med slutbrugerens brug af løsningen. Hvis ikke et menneske kan interagere er det et non-funktionelt krav. Supplere med områder (kategorier fra kravmotoren). b) Kommunikation af afgrænsningen (debat) c) Muligheden for at dele funktionelle krav i løsningen (debat) Lars Faurholt, formand for styregruppen, ytrede ønske om at overveje, hvorvidt OS2kravmotor også skal kunne rumme funktionelle krav. Skal vi igangsætte en research story for at belyse dette? Drøftelser og beslutning til punkt a + b Formålet er at have et redskab til at kunne vurdere om et krav er et tværkommunalt krav. Det bemærkes at første punkt i definitionen af non-funktionelle krav bør ændres til: Det fundament som de funktionelle krav ikke anvendes på. Side: 3

4 Det bemærkes endvidere at et non-funktionelt krav umiddelbart er krav der kan genbruges på tværs af systemer. Kravredaktionen beslutter at krav der hører hjemme i kravmotoren er af denne form: En kombination af non-funktionelle krav og krav som kan genbruges på tværs af systemer. Formuleringen godkendes og den sendes på sprogligt på værksted hos Henrik som efterfølgende sender den ud på mail til endelig godkendelse. Det besluttes at teksten skal vises som en vejledning når man i OS2kravmotor vælger at ophøje et krav. Endvidere skal der tilføjes et menupunkt i venstre side som referere til denne og andre vejledninger. Det noteres at punkt b er selve kommunikationen omkring det som besluttes under punkt a. Note: Vejledningen er efterfølgende publiseret på OS2viden, Drøftelser og beslutning til punkt c Det drøftes at organiseringen skal overvejes kraftigt da der skal være fagfolk som skal kunne vurdere de krav som lægges i løsningen. I hvert fald hvis vi skal have funktionelle krav på tværkommunalt niveau. Kravredaktionen har i dag ikke ressourcerne eller kompetencerne til at løfte opgaven. Man kommer frem til at der umiddelbart er to veje: En redaktion som sortere i de krav der skal være fælles. Eller funktionalitet som gør at man kan dele krav man selv har stillet i forbindelse med et udbud med andre. Men helt uden redaktionel involvering. o Det kan f.eks. være i form af videns-pakker som gøres tilgængelige. Man drøfter endvidere at det hurtigt kan blive en rodekasse hvis ikke ressourcerne er der til at rydde op og kvalificere. Man kommer frem til at den reelle værdi ligger i at kommuner kan få adgang til at se hvilke krav andre stiller. Kravredaktionen er derfor fortaler for en videnbank hvor man kan dele sine krav råt. En slags: Sådan blev det gjort hos Kommune a, b, c. Kravredaktionen indstiller til styregruppen at denne skal overveje om OS2kravmotor løsningen skal knopskyde eller om vi skal styre den indenfor en specifik retning. Det besluttes at emnet kræver yderligere drøftelser og kan komme med på næste møde. Men først og fremmest skal styregruppen have mulighed til at komme med yderligere overvejelser. Side: 4

5 Dagsordenpunkt 4, Indstilling til udvikling af ny funktionalitet. Orientering Styregruppen har besluttet, at der i user stories skal tilføjes tre linjer om, hvorfor man gerne vil lave en ændring: - se punkt 5 Se bilag 1 Det besluttes at en user story fremover skal indeholde beskrivelse som begrunder hvorfor man gerne vil lave en ændring. Dagsordenpunkt 5, Leverandørmøde d. 19. marts i Århus. Orientering og drøftelse Agenda for dagen: 1. Gennemgang af løsningen med fokus på leverandørvendt funktionalitet 2. Gennemgang af de 75 fælleskommunale krav 3. Er der brug for leverandørdialog i OS2kravmotor-regi? Vi skal på mødet også drøfte leverandørernes interesse i at betale for adgang til OS2kravmotor. Styregruppen har foreslået prislejet kr/året og i onboarding. Systematic, Magenta, Bellcom og Miracle har meldt deres ankomst. Det konkluderes at 4 leverandører som deltager er nok til at mødet afholdes. Leverandørernes tilslutning og eventuel betaling drøftes af kravredaktionen. Tesen er at leverandørernes interesse vil være hvis de kan påvirke kravene. Sekundært er der en lille værdi i at kunne se standardkravene man bliver udsat for. Men som leverandør vil man nok forvente garanti for at det så også er de krav man udsættes for. Der er i kravredaktionen en holdning til at vi skal være forsigtige med at opkræve tilslutningsgebyr fra leverandørerne. Det kan forvride markedet da nogen kan få en konkurrencefordel. Der argumenteres for at viden bare skal være tilgængelig. Eller at leverandørerne kan være med til at betale for at vi stiller gode krav ad andre veje. F.eks. ved at finanserne den udvikling som skal til for at løsningen har den nødvendige funktionalitet. Man mener at der for leverandørerne er værdi i at man kan se og forstå kravene og dermed bedre kan forstå behovene. Vi vil gerne have input til hvordan omkostninger til at lukke leverandører ind kan dækkes. Det besluttes at opsamle argumenter for og imod leverandørbetaling så styregruppen kan forhold sig til emnet. Det besluttes at spørge på leverandørmødet Kravredaktionen er umiddelbart i mod leverandørbetaling via abonnement og det besluttes at styregruppen på næste møde skal drøfte input fra kravredaktionen. Side: 5

6 Dagsordenpunkt 6, Konsulentbistand. Beslutning Styregruppen har afsat kr. om året til konsulentydelser se budget. Brian er tilknyttet i 2018 som både kravkonsulent og leverandør af ny funktionalitet. Fra 2019 skal der være to forskellige leverandører på disse to ydelser. Vi skal komme med et bud på, hvem der kan tage over fra Se punkt 6: Inden drøftelsen bedes leverandøren forlade lokalet. Leverandøren kommer med følgende input inden lokalet forlades. Leverandøren støtter op omkring at der findes en anden konsulent/leverandør så nuværende leverandør ikke sidder med dobbeltrollen i fremtiden. I 2018 er det rigtig godt at have leverandøren som står for funktionalitet dybt involveret. Kravredaktionen vil fra 1/ sikre at der er tilknyttet en ekstern konsulent. Enten en alternativ leverandør til funktionaliteten og nuværende som kravkonsulent. Eller en alternativ kravkonsulent. Kravredaktionen vil komme med en indstilling tids nok så styregruppen kan forholde sig til den. Inden næste møde byder medlemmer af kravredaktionen ind med input til type og/eller et navn. Kravredaktionen drøfter videre på næste møde. Kravredaktionen ønsker at kunne trække på nogen som er tæt på et udviklerhus. Drøftelser går efterfølgende over i hvordan er det styregruppen ønsker den fremtidige organisering skal være. Hvilken model ønsker vi at arbejde med. Skal vi sigte mod at produktet har et dedikeret sekretariat. Over tid opstår der et behov for et mere etableret sekretariat. Dette spørgsmål ønsker kravredaktionen at sende videre til styregruppen. Dagsordenpunkt 7, Nye krav eller revision af eksisterende krav. Beslutning a) Revision af eksisterende krav: # Krav svartider Løsningens brugergrænseflade skal være responsiv og understøtte brugernes arbejde uden unødig ventetid. Leverandøren skal, i forbindelse med afgivelse af tilbud, angive forventede svartider i løsningens brugergrænseflade, angivet som: gennemsnitssvartider for simple operationer (almindelig navigation i brugergrænsefladen) gennemsnitssvartider for komplekse operationer (fx større/komplekse søgninger, hentning af store mængde data, osv) b) Revision af eksisterende krav: # Krav oppetid Løsningen skal være tilgængelig for brugernes anvendelse i den primære driftstid. Den primære driftstid er 6-18 for løsninger der anvendes i normal kontortid, og 24/7 for løsninger der altid er i anvendelse. Leverandøren skal, i forbindelse med afgivelse af tilbud, medsende dokumentation på den oppetid der tilbydes på løsningen, målt på månedsbasis. Side: 6

7 Oppetiden kan angives som en procentsats (fx 99,9% oppetid), eller som en samlet maksimal nedetid over en kalendermåned (fx 3 timer og 20 minutter). Korrekt varslede servicevinduer tæller i den sammenhæng ikke som nedetid. c) Revision af eksisterende krav: # Krav servicevinduer Leverandøren skal, i forbindelse med afgivelse af tilbud, medsende dokumentation på de SLA niveauer som tilbydes, herunder beskrivelse af processer for softwareopdateringer, serveropdateringer, databaseopdateringer m.m. i forbindelse med servicevinduer Leverandøren skal, for hvert tilbudt SLA niveau, angive som minimum følgende oplysninger maksimalt antal servicevinduer indefor en given kalenderperiode omfang af servicevinduet, herunder beskrivelse af maksimal nedetid varslingsperiode for servicevinduer d) Revision af eksisterende krav: # Krav Dokumentation af løsningen Leverandøren skal, i forbindelse med afgivelse af tilbud, medsende dokumentation på løsningen, der dækker nedenstående områder i det omfang det giver meningen for løsningen Arkitekturbeskrivelse af Løsningen Driftshåndbog der dækker de områder der involverer Kommunen Brugermanuel til løsningen Teknisk dokumentation af udstillede snitflader Dokumentation af den rolle/rettighedsmodel der anvendes af Løsningen, herunder roller og rollebeskrivelse Dokumentationen vil indgå i en samlet vurdering af løsningen e) Revision af eksisterende krav: # Krav 188 kravet bør begrundes, så leverandører og kommune kan få en bedre, så leverandører og kommune kan få en bedre dialog om emnet. Det kan evt. ske via eksempler på manglende anvendelse af standarder f) Revision af eksisterende krav: Hvor ønsker vi bilag knyttet til krav? Grundet tidsmangel besluttes det at punkt 7 håndteres på efter mødet. OS2-sekretariatet laver gennemgang af stavning osv. inden. Dagsordenpunkt 8 [60 min] Hovedgreb og løbende proces omkring arbejdet med krav vedr. GDPR/informationssikkerhed. Beslutning og drøftelse a) Brian har til mødet forberedt: En status på de eksisterende krav med relation tit GDPR hvad dækker de og hvor er der huller Et kig på de 145 forslag til krav fra Digitaliseringsforeningen (medsendt) og hvor der er overlap og nyt input til OS2kravmotor - krav og/eller bilag Et forslag til filtre der klassificerer datas følsomhed b) Henrik har snakket med Dan Bjørneboe, KL, omkring muligheden for at trække på juridisk rådgivning fra KL c) Kan skema fra Grunddataprogrammet indarbejdes i OS2kravmotor? Jf. mail fra Mia Bastrup (medsendt) Side: 7

8 d) Fremtidig proces - på baggrund af disse input tages stilling til hvilken proces omkring GDPR, der skal følges fremad Inspirationslæsning: 1. (fra Carsten) Digitaliseringsstyrelsen: Sådan stiller du krav til leverandører om informationssikkerhed (fra Michael Jensen, Det storkøbenhavnske Digitaliseringsfællesskab) Udkast til krav om compliance med persondatalovgivning og sikkerhedsstandarder, KOMBIT: %20KOMBIT%20- %20Udkast%20til%20krav%20om%20compliance%20med%20persondatalovgivning%20og%20si kkerhedsstandarder.pdf Brian vedhæftede slides i bilaget: GDPR.pptx. Vi har allerede 4 krav 176, 183, 187 og 232 som dækker GDPR. Krav 187 skal fintunes. Der skal stå hvilke data løsningen har registreret og ikke kommunen. Krav 232 skal redigeres når GDRP er trådt i kraft. Argumentet er at vi med de 4 krav vi allerede har er dækket godt ind. Vi behøves ikke have krav som dækker om man overhovedet må behandle persondata for det må kommuner via anden lovgivning. Vi er godt dækket ind i kravmotoren med generelle krav. Men i takt med at der arbejdes med emnet i kommunerne skal der lyttes til det arbejde. Kravredaktionen bestiller et krav hos leverandøren omkring opnåelse af sikringsniveau 3. Kravet behandles på kommende møde. De 145 krav fra DIGIT er gennemgået og der er 3 krav som kan linkes direkte til GDPR. Krav 6 er en skarpere formulering af krav 187. Det besluttes at de to smeltes sammen. Krav 127. kan fortolkes som et privacy by design krav. Kravet omhandler at man skal have en grund til at bede om data. Men i virkeligheden er dette krav jo kundens eget ansvar. Det besluttes at dette krav ikke skal med, begrundelsen er at det i sidste ende er kommunenes eget snsvar. Krav 128, det besluttes at dette krav lægges på køl da vi er dækket ind af krav om databehandleraftale. De 145 DIGIT krav er meget detaljerede krav men mange kan godt være relevante. En kommende funktionalitet i OS2kravmotor kunne være kravpakker som man kan til vælge, f.eks. en iso pakke. Side: 8

9 Dagsordenpunkt 9 Nyt filter, ændring af filterindstilling. Beslutning A. nyt filter: Skal løsningen bruge eller give data til andre løsninger? B. nyt filter: System til sagsbehandling *Tekst* Skal den ønskede løsning bruges til sagsbehandling, fx * Dokumentation af sagsbehandling * Arkivering af sager, dokumenter og/eller ydelser *Krav der rammes* Integration med Digital Post Journalisering af mails fra outlook/exchange C. Ændring af filterindstillinger for # Krav 191 omkring RPA, så kravet kommer med altid D. Ændring af filterindstillinger for # Krav 222 omkring WCAG, så kravet kommer med, når løsningen bruges af borgere Punkt a Det er et filter som påvirker mange krav. Men er filtreret overhovedet relevant, vil man nogensinde skulle bruge dette filter? Det modstrider den fællesoffentlige arkitektur om at systemer skal snakke samme. Kravredaktionen beslutter at det ikke skal ind i løsningen. Henrik følger op med Ghita. Punkt b Filtreret godkendes og skal med i OS2kravmotor. Det afføder at nye ESDH krav skal oprettes. Dette afsluttes endeligt på mail. Punkt c Godkendt, dog har kravredaktionen argumenteret for at det kun er relevant i de tilfælde der er en GUI til rådighed. Punkt d Godkendt men med tilføjelse af at det også skal gælde medarbejdere. Side: 9

10 Dagsordenpunkt 10 Ændringer af tre centrale begreber i løsningen. Beslutning A. Mia Bastrup, Fredericia har ønsket at ordet Igangværende ændres til Ny markedsdialog eller Ny kravdialog B. Leon, SKI har ønsket at ordet Indkøb ændres til Markedsdialog eller Kravdialog C. Ghita Thiesen, KL, har ønsket at ordet Fælleskommunal ændres til Tværkommunal Punkt a Det besluttes at igangværende bibeholdes og at der tilføjes et ekstra link som hedder markedsdialog. Der ligger også en mail fra Mia denne kigger Brian og Henrik på efterfølgende. Punkt b det besluttes at Indkøb ændres til Markedsdialog. Der skal konsekvensrettes. Punkt c Det besluttes at der ændres til Tværkommunal. Dagsordenpunkt 11 Næste møde. Beslutning Næste møde er 14. juni 2018 a) Hvor skal vi mødes? b) Input til agenda Næste møde planlægges via Doodle og indkaldes snarest. Dagsordenpunkt 12 Eventuelt Ingenting under eventuelt Side: 10