Transcript 1. Funksjonelle krav til løsning - data i Norge

Vedlegg 1
data.norge.no
Kravspesifikasjon for en ny allmenn tjeneste for publisering av informasjon om
offentlige datasett som er gjort tilgjengelige i maskinlesbare formater.
Dette er en foreløpig skisse til kravspesifikasjonen.
Anbudet skal omfatte organisatoriske, tekniske, økonomiske forslag for utvikling
og drift av løsning. Kunde og leverandør skal samarbeide om organiseringen av
løsningen på kunde (eier)-siden, slik at data.norge.no er sikret kvalitet tilbake
til data-produsentene, som ligger til grunn for tjenesten. Leverandørens tekniske
løsning skal harmoniseres med overordnet organisering.
Foruten teknisk løsning, skal leverandør beskrive sin organisering og krav/ønsker
til organisering hos kunde. Pris skal reflekteres på komponenter, med opsjoner for
kvalitetsalternativer, samt for organisering og fremdrift.
Driftsforslag skal harmonisere med den organisering som data.norge.no har
valgt, og leverandør skal beskrive de støttesystemer som skal sikre datafangst og
eventuelle konverteringsløsninger frem til bukerportalen.
Den tekniske løsning skal være modulær og åpen, på en slik måte at fremtidige
endringer kan skje på en smidig måte med lavest mulige kostnader. Proprietære
løsninger, med spesiell leverandør avhengighet eller avhengighet til personer, vil
bli forsøkt unngått.
Løsningen skal ha høy sikkerhet og lav sårbarhet både i sin tekniske og
organisatoriske struktur.
Koder og begreper
O – Obligatorisk
V - Valgfritt
1. Funksjonelle krav til løsning
Krav nr.
1.1
1.1.1
Beskrivelse av krav
Generelle krav
Løsningen skal bestå av en nettbasert publiseringsløsning (CMS) som
skal ha støtte for:
● Blogg (Kommentar: Det bør vurderes om dette kan leveres/
integreres ved hjelp av et spesialisert blogg verktøy som f.eks.
WordPress)
● Oppretting og vedlikehold av egne datatyper, spesifikt en
datatype for lagring og presentasjon av metadata relatert til et
offentlig tilgjengelig datasett
● Støtte for synkronisering mot ekstern datakilde for datatyper
Skisse til kravspesifikasjon for data.norge.no Side 2
Krav
type
(O/V)
O
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
1.1.7
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.2.8
Det skal være mulig å publisere dokumenter og andre filer på
nettstedet. (Kommentar: Bør støtte opplasting av multiple filer.)
Løsningen skal støtte publisering av informasjon på flere språk,
herunder rammer for levende bilder for tegnspråk på alle sider
De implementerte språkene skal kunne knyttes direkte til
nettadressene data.norge.no, data.noreg.no, data.norga.no og
data.norway.no.
Løsningen skal følge referansekatalogens krav til IT-standarder der det
er relevant. (http://standard.difi.no/) [Meningsløst krav hvis man ikke
er konkret ift. hvor det er relevant. Er bedre å være konkret under
hvert spesifikke punkt i kravspek’en og vise til konkrete standarder
som må oppfylles]
Verktøyet skal utformes i tråd med statens IKT- arkitekturprinsipper:
http://prosjektveiviseren.no/dokumenter/arkitekturprinsipper
Løsningen skal tilfredsstille kravene i W3C WAI WCAG 2.0 AA (alle
kriterier merket A og AA i standarden - http://www.w3.org/
WAI/WCAG20/quickref/Overview.php). Ved leveranse skal dette
dokumenteres.
Administrasjon av nettstedet
Innholdet på nettstedet skal kunne administreres gjennom et
webbasert grensesnitt. Det må være mulig å registrere minimum n
antall unike brukere i dette grensesnittet, der n er lik summen av
antall kommunale, fylkeskommunale, statlige og andre virksomheter.
[Bedre å angi et konkret tall i stedet for å la leverandør sitte og
regne ut dette selv] (Kommentar: Det bør også her skrives hvordan
brukerregistrering skal foregå. F.eks. skal det være mulig å registrere
bruker i bulk?)
Publiseringsløsningen må kunne håndtere ulike roller. En rolle skal
kunne styre tilgang til et utvalgt sett av innhold i løsningen. En
bruker skal kunne knyttes til en eller flere roller. (Kommentar:
Kravspesifikasjonen her burde vært skrevet ved hjelp av bruker
historier / user stories).
Det webbaserte grensesnittet for administrasjon av nettstedet skal
være en integrert del av det offentlige nettstedet.
Administrasjon av nettstedet skal krypteres med SSL.
Innlogging på nettstedet skal kunne skje med allerede etablerte
autorisasjonsløsninger. Oppgi hvilke autorisasjonsløsninger som
kan tilbys. (Kommentar: OAuth, OpenID? I så fall burde det være
muligheter for integrasjon mot ganske mange tjenester som f.eks.
Google Mail og Facebook).
Tilbudet må omfatte eventuelle andre sikkerhetsmekanismer som
anbefales. Hvis noen tilbys, angi disse.
Det må være mulig å administrere de registrerte brukerne på en
effektiv og hensiktsmessig måte. Det må også være mulig å sende
ut meldinger til deler av eller alle brukerne. (Kommentar: Hvordan
man skal sende ut meldinger må spesifiseres nærmere. Det er alt
for generelt hvordan det er beskrevet her. Man bør se på standard
løsninger for utsendelse av meldinger og ikke finne opp hjulet på nytt).
Innhold på nettstedet skal kunne tildeles spesifikke brukere, som så
har rett til å endre disse dataene. Brukere må kunne hindres fra å
redigere annet innhold. (Kommentar: Burde ikke størst mulig del av
nettsidene være åpent tilgejngelig for editering. Data.norge.no bør
være et nettsamfunn og arbeidet med vedlikehold burde gjøres av
Skisse til kravspesifikasjon for data.norge.no Side 2
O
O
V
O
O
O
V
O
V
V
O
O
1.2.9
1.2.10
1.2.11
1.2.12
1.2.13
1.2.14
1.2.15
1.2.16
1.2.17
1.2.18
1.2.19
1.2.20
1.2.21
1.3
1.3.1
samfunnet).
Det må være enkelt å skille mellom innhold som er ”eid” av en bruker,
og poster som ikke er ”eid” og altså forvaltes av administrator.
Det skal være mulig å slette innhold permanent.
Databasen skal tilfredsstille kravene til metadata beskrevet i [hva er
gode krav til metadata her?] Dette innebærer blant annet at hver post
skal inneholde feltene navn, beskrivelse, eier, url, forvaltningsnivå,
format, pris, vilkår. Oppgi hvilket merarbeid nye felter, eller endring
av eksisterende felter, vil medføre.
Alle postene skal ha en unik permanent URI. Denne nøkkelen bør være
enkel nok til å kunne bruke i en URL. URIen må være lesbar, og være
utformet slik at man skal kunne tolke hva den representerer. Spesifiser
hvordan dere ser for dere at en slik nøkkel kan være. [Kommentar fra
Kjetil Kjernsmo: det er ikke klart hva man mener med URI vs. URL her]
Det skal være mulig å kategorisere dataene på flere måter, f.eks.
etter eier, forvaltningsnivå, eiers geografiske plassering, type data og
vilkår for bruk.
Det skal være mulig å koble kontaktinformasjon for registrerte brukere
med deres tildelte datasett.
Det skal være mulig å velge å ha en knapp for tilbakemelding på hvert
datasett. Denne knappen skal bruke kontaktinformasjonen til dataeier/
registrerte brukere som alt er registrert, og gjøre det enkelt å melde
fra om feil og mangler. (Kommentar: Kan ikke tilbakemeldinger være
offentlige?).
Det skal være mulig å følge en RSS-feed med nyheter om datasett for
ett eller flere datasett. Dette skal kunne hentes hos dataeier.
Det må være mulig å lenke hver post sammen med andre eksterne
og interne ressurser, så som lenker til applikasjoner som bygger på
dataene, lenker til kildekodebibliotek man kan bruke til å analysere
dataene, og dokumenter.
“Databasen skal være versjonert. Det skal være mulig å ha flere
aktive versjoner samtidig. Det skal også være mulig å hente frem
gamle, deaktiverte versjoner av beskrivelsene. Spesifiser hvilken type
versjonering dere mener vil være mest hensiktsmessig for denne typen
data. [Versjonering av database er feil å si. Her dreier det seg om
versjonering og historikkhåndtering av innholdselementer i løsningen].
Det må være mulig å datostemple innhold etter når det sist ble
oppdatert. Dataeier må også ha mulighet til å registrere når og/eller
hvor ofte man skal forvente at datasettet oppdateres.
Administrator skal ha enkel tilgang til detaljert statistikk over bruken
av nettstedet, og kunne ta ut rapporter om f.eks. mest benyttede
søkeord, mest populære datasett, etc. (Kommentar: Bør ikke også
dette være offentlig?)
Brukere skal ha tilgang til statistikk over hvor mange ganger innholdet
de ”eier” har blitt vist.
Krav til nettstedet
Nettstedet skal omfatte følgende innholdskategorier:
● Nettstedets logo, navn, etc., som skal vises på alle sider
● Språkvalg
● Faner e.l. som hjelper brukeren å navigere mellom datakilder,
blogg og andre dokumenter og ressurser
● Aktuell driftsinformasjon
● Innlogging for informasjonsleverandører og administratorer
Skisse til kravspesifikasjon for data.norge.no Side 2
V
O
O
O
O
V
V
V
O
O
O
O
V
O
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
1.3.9
1.3.10
1.4
1.4.1
1.4.2
1.4.3
Det grafiske designet av nettstedet skal være åpent og innbydende.
Det skal tilfredsstille regjeringens krav til universell utforming[hvordan
forholder dette seg til 1.1.7?], og være moderne i en slik grad at det
kan sies å bli omfattet av et diffust begrep som ”Web 2.0-design”. [Er
dette en så vissen formulering[] at den bør tas ut?][Det kan stå, man
forstår i hvilke baner de tenker][Umulig krav å måle endelig løsning
mot, bør tas ut av en kravspesifikasjon][Helt enig, denne uttalelsen
hører ikke hjemme i et formelt dokument]
Det skal være mulig å søke etter alle dataene som ligger i
databasen.(Kommentar: Også i offentlige søketjenester som f.eks.
Google og Bing).
Sluttbruker skal kunne foreta fritekstsøk på alle tekstfelt, inkludert
avanserte søk med logiske operatorer. Ved stavefeil bør søket gi
treff på tilnærmet likt innhold. Det skal også være mulig å maskere
enkelttegn ved søk.[Hva menes med å “maskere enkelttegn”?]
Systemet har funksjoner som forhindrer at man setter i
gang tidkr”evende søk.[Dette må spesifiseres nærmere]
Det skal være mulig å avbryte et søk.(kommentar: Hva menes med
dette? Et søk vil jo alltids kunne avbryes ved å trykke Back?).
Løsningen skal støtte eksport av søkeresultat til lesbare format (pdf)
og maskinlesbare formater (se kapittel 1.5)
Det skal være mulig å få opp statistikk over hvor mange datasett som
er registrert, hvor!!!!!!!!!!! mange som er registrert på ulike eier, hvor
mange datasett som er oppdatert, etc.
Det skal være mulig å karakterisere noen datasett som populære
eller ”hotte”. Disse skal kunne profileres gjennom egne bokser på
fremsiden og/eller i sidekolonner.
Krav til bloggen
Det skal være mulig å importere alt innhold fra den nåværende
bloggen på data.norge.no inn i den nye bloggen.
Bloggen skal i all hovedsak ha den samme funksjonaliteten som den
nåværende bloggen.
Bloggen skal være basert på en utbredt bloggteknologi med et solid
utviklermiljø og mange ferdigtestede utvidelsesmoduler.
1.4.4
Bloggen skal støtte publisering vha. AtomAPI eller liknende.
1.5
1.5.1
Krav knyttet til tilgjengelighet av rådata
Dataene på nettstedet skal kunne lastes ned i maskinlesbare
formater. Dette skal kunne gjøres både samlet og i deler gjenom et
programmeringsgrensesnitt (API).
Informasjonen på nettstedet skal være tilgjengelig i formatene
xml, json og csv. Spesifiser hvilke formater dere foreslår, og
begrunn forslaget. Kommentar: Det er viktig at tjensten kan
syndikeres. Det bør derfor være mulig å hente innholdet fra
bloggen i et maskinlesbart persistent format v.h.a. REST kall).
1.5.2
1.5.3
Der det er praktisk mulig, skal dataene publiseres ved hjelp av linkede
data-prinsippene. Alle ting i databasen skal ha en HTTP URI som
representerer tingen, og når denne derefereres, skal man vises ved
en HTTP 303 Redirect til rådata om URIen. Rådataene skal da finnes
på minst formatene RDF/XML og Turtle og det skal kunne brukes HTTP
Content Negotiation for å velge format. (Kommentar: Bra prinsipp.
Bør også være mulig å overstyre Content Negotitation v.h.a. query
Skisse til kravspesifikasjon for data.norge.no Side 2
O
O
V
V
O
O
O
V
V
O
O
V
V
O
V
V
parametre?)
1.5.4
Det skal være mulig å kjøre spørringer mot linkede data ved hjelp
av spørrespråket SPARQL gjennom et HTTP SPARQL Endpoint. Det
skal også være mulig å redigere data, ved bruk av SPARQL 1.1 HTTP
Bindings og relevante sikkerhetsmekanismer, se punkt 1.2.
V
1.5.5
Dataene skal linkes til sentrale, eksisterende noder blant Linked Open
Data.
V
1.5.6
Det skal legges til rette for å la brukere legge til linker til andre
datasett i Linked Open Data.
V
2. Skisse til løsning
Krav
nr.
Beskriv”else av krav
2.1
Leverandøren må gi en skisse til løsningsforslag. Løsningsforslaget skal
minst omfatte:
● En modell for løsningen (blogg og nettsted) som synliggjør hvilke
funksjoner som inngår i løsningen og hvordan disse samvirker
● En spesifikasjon av hvilke programvarekomponenter blogg,
nettsted og database baseres på
Leverandøren bes angi hva som inngår av programvarelisenser for f.eks.
databaser, og server-programvare for at blogg, nettsted og database skal
fungere.
Oppgi hvilke deler av løsningen som baserer seg på hyllevare,
egenutviklete standardløsninger, og skreddersøm.
Dersom løsningen bygger på programvare som leverandøren ikke selv står
ansvarlig for, bes det om opplysninger om forhold mellom leverandør og
rettighetshaver, og om planer for videreutvikling av programvaren og
løsningen.
Leverandøren bes beskrive ansvarsforhold, ressurser og rutiner for
utvikling, feilretting, kvalitetskontroll og support for tilbudt tredjeparts
programvare.
Oppgi i hvilken grad og på hvilke betingelser løsningen kan tas i bruk
av andre offentlige virksomheter som ønsker å etablere tilsvarende
tjenester.
2.2
2.3
2.4
2.5
2.6
Krav
type
(O/V)
O
O
O
O
O
O
3. Generelt
Krav
nr.
Beskrivelse av krav
3.1
3.1.1
Dokumentasjon
Følgende dokumentasjon skal tilpasses oppdragsgiver og utarbeides:
● Brukerdokumentasjon for innholdsleverand”ørene
● Bruker/system-dokumentasjon for administrator
Skisse til kravspesifikasjon for data.norge.no Side 2
Krav
type
(O/V)
O
Driftsdokumentasjon for leverandør av tjenesten
Brukerveiledning for sluttbruker, tilgjengelig på nettstedet
Teknisk dokumentasjon (programvare, versjoner, plattform, osv.)
Systemet i seg selv skal være mest mulig selvforklarende, men alle
moduler og funksjoner skal beskrives i dokumentasjonen.
Det må være elektronisk hjelpefunksjon i programmet, og forklarende
tekst når du peker på et felt. [Bør det presiseres her at alle skjema skal
følge Elmer-standarden?]
●
●
●
3.1.2
3.1.3
O
V
http://standard.difi.no/forvaltningsstandarder/anvendelsesomraade/
naeringslivskjema-paa-offentlige-nettsider
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.1.9
3.2
3.2.1
3.2.2
3.2.3
3.3
3.3.1
http://standard.difi.no/forvaltningsstandarder/standard/elmer/elmer-v2
All dokumentasjon som utarbeides for løsningen skal leveres i elektronisk
form.
Leverandøren er ansvarlig for at dokumentasjonen til enhver tid samsvarer
med aktuell versjon av systemet.
Leverandøren må angi hva slags brukerdokumentasjon som inngår, hvilke
format den foreligger i og hvordan dokumentasjonen som er spesifikk for
løsningen skal utvikles.
Driftsdokumentasjon skal være så konsis at personer som ikke har deltatt i
utviklingen har mulighet til å drifte systemet.
For applikasjonen skal det utarbeides driftsdokumentasjon med oversikt
over meldinger for alle feilutganger i systemet, og med anbefaling om
aksjon. Hver feilutgang skal ha sin unike melding.
Leverandøren må angi hva slags systemdokumentasjon som inngår, format
den foreligger i, og hvordan dokumentasjon som er spesifikk for løsningen
skal utvikles.
Kildekode og rettigheter
Spesialutviklet kildekode til bloggen, databasen og nettstedet tilhører
oppdragsgiver. Oppdragsgiver står fritt til å utvikle eller forandre på
programvaren, enten med hjelp av leverandør eller med hjelp fra andre.
Spesialutviklet kildekode til bloggen, databasen og nettstedet skal
publiseres som åpen kildekode. Angi hvilken lisens som skal brukes.
Kommentar: Det burde være obligatorisk at løsningen er basert på åpen
kildekode da dette ville gi en god signal effekt på et nettsted som dette.
Spesialutviklet kildekode til bloggen, databasen og nettstedet skal
dokumenteres grundig. Det skal være mulig for andre å bruke kildekoden
til å sette opp tilsvarende nettsteder. Dokumentasjonsspr”åket er engelsk.
Utvidelsesmuligheter
Leverandøren må beskrive hvordan løsningen på et senere tidspunkt
kan utvides til å være en tjeneste der det for små dataeiere som ikke
nødvendigvis har råd til å sette opp egne servere vil være mulig å lagre
selve dataene på en server som tilhører nettstedet data.norge.no.
O
O
O
O
O
O
O
V
V
O
4. Test
Krav
nr.
Beskrivelse av krav
Skisse til kravspesifikasjon for data.norge.no Side 2
Krav
type
(O/V)
4.1
4.2
4.3
Leverandøren forventes å samarbeide med oppdragsgiver om en plan om
testing. Det forventes at personell fra leverandøren er tilgjengelig under
testfasen. I testplanen skal det fremgå hvordan henholdsvis leverandør og
oppdragsgiver skal delta. Beskriv hvordan leverandøren forholder seg til
dette.
Leverandøren må oppgi hvordan systemet kan testes (simulert) for ulike
antall brukere.
Leverandør må ha egnede prosedyrer for endringshåndtering. Hvem og
hvordan besluttes endringer? Beskriv eventuelle prosesser og prosedyrer
rundt dette.
O
O
O
5. Teknisk infrastruktur og tekniske løsninger
Krav
nr.
Beskrivelse av krav
5.1
5.2
Oppgi om leverandøren tilbyr driften selv eller via tredjepart.
Leverandøren bes med utgangspunkt i den foreligg”ende informasjon,
samt krav til belastning og oppetid (se videre i spesifikasjonen), om å
beskrive sitt løsningsforslag på et overordnet nivå. Løsningsforslaget skal
omfatte:
5.3
5.4
En arkitekturskisse av driftsløsningen som viser hvilke
arkitekturkomponenter som inngår i løsningen, og hvordan disse
samvirker. Skissen skal vise brannmurer, nettverkstopologi, DMZ, og
reserveløsning for å garantere ønsket driftskvalitet og driftskapasitet.
Leverandøren bes beskrive løsningens åpenhet og fleksibilitet med
henhold til bytte av driftsleverandør.
Leverandøren bes beskrive løsningens utbredelse i markedet og tilgang
på kompetanse rundt løsningen i markedet. Dersom det er noen deler av
løsningen som avviker i forhold til utbredelse og kompetanse for løsningen
som helhet, må dette spesifiseres.
Krav
type
(O/V)
O
O
O
O
hva er ønsket?
6. Drift og vedlikehold
Krav
nr.
Beskrivelse av krav
6.1
6.1.1
Vedlikeholdskontrakt
Leverandøren bes utarbeide et forslag til vedlikeholdskontrakt for
løsningen med definert servicenivå (se videre i spesifikasjonen) og
kostnadsestimat. Kontrakten skal gjelde for to år etter garantitidens utløp
og gi mulighet til forlengelse.
Kompetanse i driftsfasen
Leverandøren skal vedlikeholde sin kompetanse på drift av løsningen
under hele driftsperioden.
Servicenivå, oppetid og kostnader
Leverandøren må tilby brukerstøtte på forespørsel fra oppdragsgiver.
Servicepersonell må ha den riktige kompetansen basert på de
6.2
6.2.1
6.3
6.3.1
Skisse til kravspesifikasjon for data.norge.no Side 2
Krav
type
(O/V)
O
O
O
6.3.2
6.3.3
6.3.4
6.3.5
6.3.6
6.3.7
6.3.8
6.3.9
6.3.1
0
6.3.1
1
6.3.1
2
6.3.1
3
6.4
6.4.1
6.4.2
6.4.3
6.4.4
6.4.5
6.4.6
6.5
driftssituasjoner som erfares.
Servicepersonell skal være tilg”jengelig via telefon og epost.
Leverandøren bes utarbeide oversikt over tjenester med pristabell.
Leverandøren må ha reserveløsninger på programvare, maskinvare og
nettverk.
Nettstedet og applikasjonen forventes å være tilgjengelig syv dager i uken
(24/7).
Leverandøren må garantere 99.5 % oppetid, og vise pristabell for ulike
avvik fra garantien. Hvis garantien differensieres på dagtid og nattid,
helger og helligdager må dette også beskrives. Prosentberegninger for
oppetid beregnes inkludert planlagt tid for vedlikehold.
Tilbudet må omfatte en pristabell som viser pris for henholdsvis drift og
brukerstøtte i ulike perioder i døgnet.
Leverandøren må angi trinnvis refusjon i månedlig avtalebeløp dersom
krav til oppetid ikke ivaretas. Skalaen skal være slik at månedlig
avtalebeløp bortfaller i sin helhet dersom månedlig oppetid er lavere enn
96 % innen avtalt oppetid.
Leverandøren må garantere backup som er maksimalt 24 timer gammel –
og dokumentere at det finnes rutiner for å teste at alle backuper er valide
og mulige å legge tilbake. Backup skal lagres i en annen bygning enn der
produksjonsanlegget er plassert.
Leverandøren må dokumentere at rutiner og driftsmiljøet er tilrettelagt
for døgnkontinuerlig og sikkert drift.
Leverandøren må dokumentere hva slags beredskapsplan man har og
definere garantert recovery-tid etter ulike typer driftsbrudd/hendelser.
Restore av data skal starte seneste 2 timer etter at oppdragsgiver har
meldt behovet.
Leverandøren må påta seg å levere feilrapporter etter driftsavbrudd.
Leverandøren må ta ansvaret for å avholde månedlig driftsmøte eller ved
behov med oppdragsgiver.
Systemet skal føre logg over alle hendelser.
Kapasitet, ytelse og utvidbarhet
Leverandøren bes sannsynliggjøre at løsningen kan håndtere den aktuelle
dokument- og trafikkmengde samt beskrive kapasitet og ytels”e for
foreslått løsning.
Leverandøren må garantere stor nok og fleksibel nok serverpark
samt tilstrekkelig båndbredde for å kunne håndtere eventuelle
belastningstopper.
Leverandøren bes beskrive i hvilken grad driftsløsningen kan skaleres etter
behov.
Leverandøren bes angi priser for forskjellige antall samtidige brukere.
Leverandøren bes beskrive løsningens praktiske og/eller teoretiske
begrensninger i forhold til antall brukere, antall informasjonselementer,
informasjonselementenes maksimale størrelse, løsningens maksimale
lagringskapasitet, spissbelastningskapasitet, mm.
Leverandøren må angi trinnvis refusjon i månedlig avtalebeløp dersom
krav til ytelse innenfor avtalt antall samtidige brukere ikke ivaretas.
Skalaen skal være slik at månedlig avtalebeløp bortfaller i sin helhet
dersom månedlig gjennomsnittlig ytelse er slik at svartider øker med mer
enn 100 %.
Utvidelser og integrasjoner
Skisse til kravspesifikasjon for data.norge.no Side 2
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
V
O
O
6.5.1
6.5.2
6.5.3
6.5.4
6.7
6.7.1
6.7.2
Leverandøren bes beskrive driftmiljøets rammebetingelser for utvidelser
og integrasjoner.
Leverandøren bes beskrive hvordan installasjon og drift av utvidelser og
integrasjonsløsninger bør skje.
Leverandøren bes beskrive hvordan oppgradering av programvare,
patching og nye versjoner håndteres.
Leverandøren bes beskrive informasjonshåndtering ved oppgraderinger
eller endringer av nettstedet eller databasen.
Sikkerhetsløsninger knyttet til drift
Leverandøren bes beskrive sikkerhetsmekanismer i forbindelse med
driftsmiljø.
Oppgi om alle krav til sikker kommunikasjon og som antas å berøre
applikasjonen og infrastrukturen, er ivaretatt.
O
O
O
O
O
O
“
organisering av support funksjonen. ansvarskart
driftsansvars hos systemeier
organisering av datavedlikehold
7. Fremdriftsplan
Krav
nr.
Beskrivelse av krav
7.1
Leverandøren bes fremlegge en detaljert fremdriftsplan for utvikling,
testing, installasjon, pilot og produksjonsstart.
Krav
type
(O/V)
O
organisering av prosjektet med ansvarforhold på kunde og leverandørsiden. Ansvarskart,
løp, milepeler.
8. Leverandørens forbehold
Krav
nr.
Beskrivelse av krav
8.1
“
Angi hvilke forbehold, forutsetninger og betingelser som tas.
Skisse til kravspesifikasjon for data.norge.no Side 2
Krav
type
(O/V)
V