|
|
|
# Use cases
|
|
|
|
|
|
|
|
## Innholdsprodusent
|
|
|
|
|
|
|
|
| **Nr** | **Historie** | **Akseptansekriterier** | **Løsningsforslag** |
|
|
|
|
| --- | -------- | ------------------- | ------------------- |
|
|
|
|
| 1 | Som innholdsprodusent ønsker jeg å enkelt kunne legge til nye filer både til ny standard og ny versjon av standard. | Fil skal kunne legges til via et GUI som er integrert med Windows utforsker. | Løses ved hjelp av Git Extensions. Innholdsprodusent kan legge til filer ved hjelp av git. |
|
|
|
|
| 2 | Som innholdsprodusent ønsker jeg at arkivet bevarer strukturen som er spesifisert opprinnelig. | | Systemet endrer ikke på strukturen i arkivet uten at innholdsprodusenten selv endrer den. |
|
|
|
|
| 3 | Som innholdsprodusent ønsker jeg å kunne opprette arbeidsversjoner av arkivet slik at endringer i denne ikke påvirker allerede eksisterende innhold i arkivet. | Lokal kopi av arkivet skal være eksakt lik internt arkiv (master) når denne opprettes. Endring i arbeidskopi skal ikke påvirke andre instanser av arkivet, med mindre man følger vedtatt prosess for oppdatering. | Dette behovet dekkes av branching. Ved å lage en branch ut fra master vil man få en arbeidsversjon som ikke påvirker andre versjoner. Vedtatt prosess for oppdatering tilfredsstilles ved hjelp av merge request. Kan også tilfredsstilles med forking. |
|
|
|
|
| 4 | Som innholdsprodusent ønsker jeg å kunne samarbeide med andre produsenter om utvikling av innhold uavhengig av gjeldende versjoner i internt arkiv og offentlig arkiv. | Det skal være mulig å jobbe på et område av arkivet som deles med andre produsenter i en arbeidsversjon av arkivet som ikke påvirker andre instanser av arkivet. | Dette behovet løses ved hjelp av forking. Det gir mulighet for å styre tilgangsrettigheter. Endringer fra fork tas inn i master på samme måte som for branches, med merge request. |
|
|
|
|
| 5 | Som innholdsprodusent ønsker jeg å selv kunne tilordne tilgangsrettigheter til arbeidsversjoner. | | Dette kraver at man lager sin egen fork, og gir aktuelle brukere tilgang til dette. |
|
|
|
|
| 6 | Som innholdsprodusent ønsker jeg å ha tilgang til arkivinnholdet offline. | Det skal være mulig å jobbe på en instans av arkivet offline, basert på en kopi av arkivet. | Løses ved hjelp av git, hvor det er mulig å jobbe videre, med versjonering, uten å være tilkoblet. |
|
|
|
|
| 7 | Som innholdsprodusent ønsker jeg å kunne sjekke inn endrede filer til arkivet. | Det skal være mulig å sjekke inn en eller flere filer samtidig. Det skal være mulig å sjekke inn kun angitte filer. Skal kunne gjøres via GUI. | Løses gjennom staging i git. Innholdsprodusent velger hvilke filer som skal sjekkes inn gjennom staging. |
|
|
|
|
| 8 | Som innholdsprodusent ønsker jeg å få oversikt over versjonskontrollhistorikken – hvem som har gjort hvilke endringer | Skal kunne aksesseres via GUI, gjelder per fil | Løses gjennom historikk i Git Extentions, med blame for å se spesifikke endringer. |
|
|
|
|
| 9 | *Som forslagsstiller ønsker jeg å kunne foreslå endringer i dokumenter.* | *UTGÅR* | |
|
|
|
|
| 10 | Som innholdsprodusent ønsker jeg å kunne legge til kommentarer til endringer jeg sjekker inn. | Skal kunne gjøres via GUI | Ved commit legges det til en kommentar gjennom grensesnittet. Commit blir ikke akseptert uten melding. |
|
|
|
|
| 11 | Som innholdsprodusent ønsker jeg å kunne hente ut arkivet for lokal lagring | Skal kunne gjøres via GUI. Bruker skal kunne velge hvor kopien skal lagres | Løses ved på benytte Git Extension for å klone repositoryet. |
|
|
|
|
|
|
|
|
|
|
|
|
## Innholdskonsument
|
|
|
|
|
|
|
|
| **Nr** | **Historie** | **Akseptansekriterier** | **Løsningsforslag** |
|
|
|
|
| --- | -------- | ------------------- | ------------------- |
|
|
|
|
| 12 | Som innholdskonsument ønsker jeg rask og enkel tilgang til publisert innhold i arkivet. | Publisert innhold skal være tilgjengelig via Internett og helsenettet. Innhold tilgjengelig på Internett skal kunne leses både maskinelt via APIer og menneskelesbart via nettleser. Innhold tilgjengelig på helsenettet skal kunne leses både maskinelt via APIer og menneskelesbart via nettleser. Datagrunnlag for Internett og helsenettet skal være det samme | Løses ved å ha en innsynsløsning laget i ASP.Net. Denne har et Web API som gjør det maskinelt lesbart, og en angular.js-frontend som benytter samme API. |
|
|
|
|
| 13 | Som innholdskonsument ønsker jeg å kunne finne all dokumentasjon knyttet til en standard basert på versjonsnummer eller namespace. | Det skal være mulig å navigere til en bestemt versjon av en standard, og se filene knyttet til denne. Det skal være mulig å søke etter en bestemt versjon av en standard eller fil, basert på et sett med søkekriterier. Det skal være mulig å finne et bestemt XML-skjema basert på namespace. | **Fortsatt litt uklart**. Basert på manifestfil/mappestruktur vil innsynsløsninga gjøre det mulig å gå inn på en standard eller versjon av den. Det vil også være mulig å søke, hvilke søkekriterier som er ønskelige er fortsatt uklart. Namespace vli peke på XML-skjema (xsd?). |
|
|
|
|
| 14 | *Som innholdskonsument ønsker jeg å kunne få oversikt over dokumentasjonen uten å måtte laste ned og/eller lese alt.* | *UTGÅR, dekket av 13* | Se 13.|
|
|
|
|
| 15 | Som innholdskonsument ønsker jeg å kunne lese/laste ned enkelt-filer når det måtte passe. | Det skal være mulig å klikke på en lenke til filen for enten å vise filen eller laste ned. Det skal være mulig å gjøre dette i arkivets avtalte oppetid. | Det vil være mulig å laste ned og lenke til enkeltfiler i arkivet, eventuelt også pakkede versjoner med alt tilhørende en standard eller en versjon av en standard. Dette vil gjelder innsynsløsningen i asp.net, ikke gitlab. |
|
|
|
|
| 16a | Som innholdskonsument ønsker jeg varsling ved endringer, tillegg eller når ny dokumentasjon blir tilgjengelig. | Det skal være mulig å abonnere på varslinger. Det skal gå ut en e-post eller tilsvarende til de som abonnerer på varslingen ved endringer, tillegg eller når ny dokumentasjon blir tilgjengelig. | **Fortsatt litt uklart**. Det skal være mulig å få melding via e-post når det kommer oppdateringer til en standard. |
|
|
|
|
| 16b | Som innholdskonsument ønsker jeg tydelig visning ved endringer, tillegg eller når ny dokumentasjon blir tilgjengelig. | Vise antall dager/måned/år siden siste endring | **Fortsatt litt uklart**. Her kan vi hente inn endringslogg fra git, eller ha en change log som er skreddersydd eksterne. |
|
|
|
|
|
|
|
|
|
|
|
|
## Innholdsansvarlig
|
|
|
|
|
|
|
|
| **Nr** | **Historie** | **Akseptansekriterier** | **Løsningsforslag** |
|
|
|
|
| --- | -------- | ------------------- | ------------------- |
|
|
|
|
| 17 | Som ansvarlig for innhold ønsker jeg å hindre publisering av nytt innhold i arkivet uten min godkjenning. | Det må være tilgangsstyrt hvem som skal kunne godkjenne publisering til offentlig arkiv | Master-branch og release-branch vil det kun være master (Innholdsansvarlig) som har tilgang til å commite til, så prosessen for å publisere til offentlig arkiv vil være å først få godkjent en merge request til master. Deretter vil master pushe fra master til offentlig master (release), potensient gjennom en release candidate-branch, hvis det kan bli behov for fixes. |
|
|
|
|
| 18 | Som ansvarlig for innhold ønsker jeg å få oversikt over alle endringer som har skjedd fra forrige godkjente versjon. | Det skal være mulig å se differansen i filinnhold mellom forrige godkjente versjon og ny fil til godkjenning. | I en merge request vil det være en oversikt over alle commits som inngår, slik at det er mulighet for å se alle endringene. Det er også mulig å se endringer ned på diff-detaljnivå. |
|
|
|
|
| 19 | *Som ansvarlig for innhold ønsker jeg å få oversikt over alle forslag til endringer som har blitt avvist.* | *UTGÅR* | |
|
|
|
|
| 20 | Som ansvarlig for innhold ønsker jeg å kunne legge til release-dokumentasjon i forbindelse med godkjenning av versjon. | Releasedokumentasjon skal være tilgjengelig sammen med filversjon | **Fortsatt litt uklart**. Usikker hvordan denne prosessen nøyaktig blir, men det vil mest trolig være aktuelt i en release-candidate-branch eller i featurebranchen før den blir tatt inn i master. |
|
|
|
|
| 21 | *Som ansvarlig for innhold ønsker jeg å kunne angi hvilke personer som skal kunne inneha rollene som innholdsprodusenter for det innhold jeg er ansvarlig for.* | *UTGÅR* | | |
|
|
|
\ No newline at end of file |