| |
|
Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring |
En lokal datasettkatalog med virksomhetsintern informasjon, til bruk for “orden i eget hus”, GDPR, statistikk etc og som er grunnlaget for informasjonen som synliggjøres i felles datakatalog |
| |
|
Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring |
Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. |
| |
|
Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring |
For å ta i bruk dataene må tilgangen til opplysningene være beskrevet gjennom API-beskrivelser. API-ene må beskrives og forvaltes av dataeier (eller distributør) (API Management), og inkludere detaljer som protokoller, utvekslingsformater, sikkerhetskrav, innholdsstrukturer, avhengigheter til kodelister, terms of service m.m. API-beskrivelsene vil finnes som en del av datakatalogen. (2018). |
| |
|
Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring |
GDPR artikkel 30 stiller krav til protokoll. Tolkes litt ulikt om det er en protokoll pr behandling eller en samlet protokoll med oversikt over alle behandlingene. Uansett er hensikten å kunne gi en samlet oversikt over behandlingen av personopplysninger i en virksomhet. Enighet om at dette løses ved at det legges til en modul for å registrere en behandlingsaktivitet. Summen av de registrerte behandlingsaktivitetene utgjør protokollen. Noe informasjon vil være felles på tvers av behandlingsaktivitetene, slik som hvem som er behandlingsansvarlig (direktøren), hvem som er personvernombud etc. |
| |
|
Prosjekttutløsende behov (overordnet)- fra handlingsplanen i porteføljestyring |
Ulik representasjon av sentral informasjon, for eksempel adresse, personopplysninger og organisasjoner medfører et løpende integrasjonsarbeid og risiko for kvalitetsforringelser. EU er pådriver for etablering av informasjonsmodeller som forener ulike land og virksomheters representasjoner og reduserer kostnaden for sammenstilling av data. Lokalt betyr dette også for BRSys en mer sømløs integrasjon mellom registrene. Altinn har verktøystøtte for informasjonsmodellering i dag (SERES) som vil migreres til ny arkitektur (2017) og etter hvert knyttes tettere til Tjenester 3.0 |
| |
|
Registrering av lokale datasett |
Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... |
| |
|
Krav (EPOS og nødvendige krav) |
(Behov for begreper i FDK søkeløsning) |
| |
|
Krav (EPOS og nødvendige krav) |
Behov for å publisere begreper eksternt (ORDEN-584) |
| |
|
Krav (EPOS og nødvendige krav) |
Integrasjon med AD |
| |
|
Krav (EPOS og nødvendige krav) |
Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... |
| |
|
Krav (EPOS og nødvendige krav) |
Støtte for arbeidsflyt |
| |
|
Krav (EPOS og nødvendige krav) |
Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt |
| |
|
Krav (EPOS og nødvendige krav) |
Intern kontaktperson |
| |
|
Krav (EPOS og nødvendige krav) |
Som informasjonsarkitekt ønsker jeg å kunne finne representasjoner av sentrale ressurser slik at jeg kan gjenbruke andres modeller og redusere semantisk friksjon |
| |
|
Krav (EPOS og nødvendige krav) |
Som virksomhet som behandler personopplysninger ønsker jeg [verktøystøtte] slik at jeg ivaretar kravene til protokoll iht GDPR artikkel 30 (protokoll) |
| |
|
Krav (EPOS og nødvendige krav) |
Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester |
| |
|
Krav (EPOS og nødvendige krav) |
Som API-konsument ønsker jeg å kunne søke og filtrer på API-er slik at jeg kan raskt finne rett API |
| |
|
Krav (EPOS og nødvendige krav) |
Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre |
| |
|
Krav (EPOS og nødvendige krav) |
Beskrive endepunkt (FDK-575) |
| |
|
Krav (EPOS og nødvendige krav) |
(Behov for registrering av begreper) |
| |
|
Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... |
Støtte for arbeidsflyt |
| |
|
Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... |
Intern kontaktperson |
| |
|
Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... |
Integrasjon med AD |
| |
|
Som virksomhet ønsker jeg en egen oversikt for intern bruk over datasett slik at... |
En lokal datasettkatalog med virksomhetsintern informasjon, til bruk for “orden i eget hus”, GDPR, statistikk etc og som er grunnlaget for informasjonen som synliggjøres i felles datakatalog |
| |
|
Som virksomhet som behandler personopplysninger ønsker jeg [verktøystøtte] slik at jeg ivaretar kravene til protokoll iht GDPR artikkel 30 (protokoll) |
GDPR artikkel 30 stiller krav til protokoll. Tolkes litt ulikt om det er en protokoll pr behandling eller en samlet protokoll med oversikt over alle behandlingene. Uansett er hensikten å kunne gi en samlet oversikt over behandlingen av personopplysninger i en virksomhet. Enighet om at dette løses ved at det legges til en modul for å registrere en behandlingsaktivitet. Summen av de registrerte behandlingsaktivitetene utgjør protokollen. Noe informasjon vil være felles på tvers av behandlingsaktivitetene, slik som hvem som er behandlingsansvarlig (direktøren), hvem som er personvernombud etc. |
| |
|
Behov for å publisere begreper eksternt (ORDEN-584) |
Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. |
| |
|
Behov for å publisere begreper eksternt (ORDEN-584) |
Publisere begreper til FDK (aka Jira adapter) (ORDEN-596) |
| |
|
(Behov for begreper i FDK søkeløsning) |
Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. |
| |
|
(Behov for begreper i FDK søkeløsning) |
Beskrive endepunkt (FDK-575) |
| |
|
(Behov for registrering av begreper) |
Som ansvarlig virksomhet (begrepseier) ønsker jeg å kunne dele begreper med andre etter anbefalte standarder, slik at andre virksomheter (menneske og maskin) kan se begreper innenfor vårt domene. |
| |
|
(Behov for registrering av begreper) |
Som begrepseier ønsker jeg å dele begrepsinnholdet mitt inn i gitte felter, slik at jeg kan beskrive begrep i tråd med anbefalte standarder |
| |
|
MVP søketjeneste API |
Som API-konsument ønsker jeg at API-beskrivelser samles slik at det er lett å få oversikt |
| |
|
Registreringstjeneste API |
Som API-forvalter ønsker jeg å registrere mine API-er slik at de kan gjøres tilgjengelig for andre |
| |
|
Ferdig søketjeneste API |
Som API-konsument ønsker jeg å kunne søke og filtrer på API-er slik at jeg kan raskt finne rett API |
| |
|
Ferdig søketjeneste API |
Som API-konsument ønsker jeg å finne detaljert beskrivelse av API-ene slik at jeg kan vurdere om jeg kan benytte API-et i mine tjenester |
| |
|
Ferdig søketjeneste API |
Som API-konsument ønsker jeg dialog med andre API-konsumenter og API-tilbydere slik at vi få hjelp og hjelpe hverandre |
| |
|
Registrering av protokoll/behanlingsaktiviteter |
Som virksomhet som behandler personopplysninger ønsker jeg [verktøystøtte] slik at jeg ivaretar kravene til protokoll iht GDPR artikkel 30 (protokoll) |
| |
|
Jira-adapter begrepskatalog |
Behov for å publisere begreper eksternt (ORDEN-584) |
| |
|
MVP søketjeneste informasjonsmodeller |
Som informasjonsarkitekt ønsker jeg å kunne finne representasjoner av sentrale ressurser slik at jeg kan gjenbruke andres modeller og redusere semantisk friksjon |
| |
|
Registreringstjeneste begrep |
(Behov for registrering av begreper) |
| |
|
Datasettkatalog |
API-katalog |
| |
|
Begrepskatalog API |
Datasettkatalog |
| |
|
Begrepskatalog API |
Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. |
| |
|
API-katalog |
Datasettkatalog |
| |
|
API-katalog |
For å ta i bruk dataene må tilgangen til opplysningene være beskrevet gjennom API-beskrivelser. API-ene må beskrives og forvaltes av dataeier (eller distributør) (API Management), og inkludere detaljer som protokoller, utvekslingsformater, sikkerhetskrav, innholdsstrukturer, avhengigheter til kodelister, terms of service m.m. API-beskrivelsene vil finnes som en del av datakatalogen. (2018). |
| |
|
en datasett-katalog i virksomheten |
GDPR artikkel 30 stiller krav til protokoll. Tolkes litt ulikt om det er en protokoll pr behandling eller en samlet protokoll med oversikt over alle behandlingene. Uansett er hensikten å kunne gi en samlet oversikt over behandlingen av personopplysninger i en virksomhet. Enighet om at dette løses ved at det legges til en modul for å registrere en behandlingsaktivitet. Summen av de registrerte behandlingsaktivitetene utgjør protokollen. Noe informasjon vil være felles på tvers av behandlingsaktivitetene, slik som hvem som er behandlingsansvarlig (direktøren), hvem som er personvernombud etc. |
| |
|
en datasett-katalog i virksomheten |
En lokal datasettkatalog med virksomhetsintern informasjon, til bruk for “orden i eget hus”, GDPR, statistikk etc og som er grunnlaget for informasjonen som synliggjøres i felles datakatalog |
| |
|
en begrepskatalog i virksomheten |
Etatene skal beskrive sin tolkning av begreper i lovverk, forvaltningsstandarder og forvaltningspraksis i egen begrepskatalog. Begrepsbeskrivelsene skal bl.a. legge til rette for at opplysningene i datasettene kan beskrives eksplisitt, f.eks. hva inngår i “likningsverdi”. Begrepsbeskrivelsene skal være tilgjengelige slik at regelverksutvikling og digitaliseringsprosjekter kan identifisere forenklinger. |
| |
|
Informasjonsmodell-katalog |
API-katalog |
| |
|
Informasjonsmodell-katalog |
Ulik representasjon av sentral informasjon, for eksempel adresse, personopplysninger og organisasjoner medfører et løpende integrasjonsarbeid og risiko for kvalitetsforringelser. EU er pådriver for etablering av informasjonsmodeller som forener ulike land og virksomheters representasjoner og reduserer kostnaden for sammenstilling av data. Lokalt betyr dette også for BRSys en mer sømløs integrasjon mellom registrene. Altinn har verktøystøtte for informasjonsmodellering i dag (SERES) som vil migreres til ny arkitektur (2017) og etter hvert knyttes tettere til Tjenester 3.0 |
| |
|
Forbedring av søketjeneste |
(Behov for begreper i FDK søkeløsning) |
