Bilag 1 Kundens kravspesifikasjon

Bilag 1 Kundens kravspesifikasjon Målet med avtalen: Avtalen omhandler et verktøy som fremstår som en rapport- og presentasjonsløsning. Overordnet funksjonalitet kan karakteriseres ved: - Rapportene vil inneholde styringsdata på utdanningsområdet på en visualisert måte. - Vise standardrapporter og tilrettelegger for kundens behov for egendefinerte rapporter og ad hoc-rapporter. - er tilrettelagt for kobling og bruk mot flere typer datakilder (kildesystem og datavarehus) Kravene i det følgende er fullstendig med hensyn til funksjonelle og tekniske krav som verktøyet skal tilfredsstille og som leverandøren slik leverandøren har beskrevet i bilag 2 og øvrige bilag har forpliktet seg til. Avtalen skal legge grunnlag for en effektiv og trygg leveranse og gi en ramme for samarbeid mellom kunde og leverandør i etableringsfasen frem til godkjenning og samarbeid knyttet til vedlikehold og mulig utvidet bruk av verktøyet. Verktøyet skal brukes av medlemsinstitusjonene i Samarbeidstiltaket FS. Avtalen skal også regulere vilkår for å kunne ta verktøyet i bruk gjennom opsjoner. Som beskrevet i bilag 3, gjelder dette eksempelvis forskningsinformasjonssystemet CRIStin og økonomisystemene, herunder primært samarbeidsprosjektet mellom universitetene i Bergen, Oslo og Trondheim. 1.1 BRUKSOMRÅDER Verktøyet skal være en rapport- og presentasjonsløsning som: - På en effektiv og brukervennlig måte støtter institusjonenes behov for data på utdanningsområdet - Tilbyr standardrapporter og tilrettelegger for institusjonenes behov for egendefinerte rapporter - Gir støtte for kontrollrapporter for bedret datakvalitet Verktøyet skal forbedre og forenkle institusjonenes forhold til egne studiedata gjennom bedret fremvisning. Det skal dekke behovet for data til alle nivå i institusjonenes, både linjeledelse og superbrukere. Se pkt. 2.3. og 2.4. for spesifikasjon av overordnete krav og krav til rapportfunksjonalitet og visualisering. 1.2 BRUKERE For at leverandøren skal ha en forståelse av Kundens bruk av verktøyet gir vi her en beskrivelse av brukerbegreper som er etablert. Brukerne skal forstås hierarkisk slik at brukere med de mest avanserte rettighetene, også har samtlige rettigheter som er mindre avansert. 1

Roller: I et verktøy kan begrepet roller spesielt knyttes til verktøyets autentiseringssystem, som identifiserer brukere og deres rettigheter. Verktøyet kan ha egne autentiseringssystemer, men må kunne knyttes til institusjonenes ordinære autentiseringssystemer, og brukernes roller bør kunne defineres der. Sluttbruker: Sluttbrukeren er tilknyttet en institusjon. Disse skal kun ha tilgang til ferdigutviklede rapporter. Sluttbrukeren skal ha tilgang til drillfunksjoner i rapportene og skal ha mulighet for å lagre rapportene med ulike utplukk. Det vil være mange ulike kategorier sluttbrukere. Noen vil kun forholde seg til et fåtall rapporter som viser situasjonen på et gitt tidspunkt. Andre brukere vil ha større behov for gode drillfunksjoner og utvalgsparametre. Sluttbruker skal kun ha tilgang til data for egen institusjon. Sluttbruker kan inngå i flere brukergrupper. Superbruker: Rollen skal innehas av en eller et fåtall personer ved den enkelte institusjon. Superbruker er UTVIKLER for internrapporter for institusjonen, og kan utvikle rapporter på vegne av institusjonen. Superbruker har førstelinje-brukerstøtte for brukere på den enkelte institusjon. Superbruker skal kun ha tilgang til data fra egen institusjon. Superbruker skal opprette brukere og administrere roller på sin institusjon. Ekspertbrukere: Det vil være en ekspertgruppe for bruken av verktøyet. Denne vil bestå av et utvalg superbrukere fra 4-6 av institusjonene som bruker verktøyet. Ved behov kan andre institusjonsbrukere inkluderes i gruppen. Deres rolle vil være å definere hvilke rapporter som skal være standardrapporter. Systemadministrator: Noen av systemadministratorne vil være utviklere for standardrapporter i systemet. Systemadministrator har brukerstøtte for institusjonenes superbrukere, og trenger derfor tilgang til data for de institusjonene de skal drive brukerstøtte for. Driftsansvarlig: Dette vil være de som er ansvarlig for drift av verktøyet, eksempelvis installasjon, oppgraderinger og overvåking. Organisering av opplæring: Systemadministrator og ekspertbrukere hos kunden skal gis nødvendig og tilstrekkelig opplæring i verktøyet til å kunne benytte verktøyet til å utvikle og gjøre tilgjengelig standardrapporter i verktøyet. Likeledes skal opplæringen være slik at de kan ivareta videre opplæring og hensiktsmessig forvaltning av verktøyets funksjonelle innhold. Driftsansvarlig hos kunden for verktøyet gis nødvendig og tilstrekkelig opplæring i de grensesnitt som verktøyet benytter slik at de selv kan foreta hensiktsmessig og sikker drift av systemet. Superbruker hos kunden vil bli opplært av systemadministratorer og ekspertgruppe hos kunden basert på dokumentasjon av de konfigureringene og rapporter som genereres ved etablering av løsningen. Sluttbruker vi få opplæring av institusjonens superbruker Kunden vil selv etablere brukerstøtte til sluttbrukere, superbrukere og ekspertbrukere. Hvordan dette skal organiseres vil avklares i forbindelse med utrullingen av systemet. 2

2 Krav 2.1 TYPE KRAV Kravene er enten kategorisert som -krav eller -krav. - : betyr et OBLIGATORISK krav som ansees som et MINIMUM for løsningen. Svar JA (kravet oppfylles) eller NEI (kravet oppfylles ikke). Alle -krav skal i tillegg besvares med en beskrivelse av hvordan kravet fylles. Funksjonalitet utover minimumskravet vil bli benyttet i rangeringen av løsningene. - : betyr en ØNSKET EGENSKAP. Svar JA (kravet oppfylles), DELVIS (kravet oppfylles delvis) eller NEI (kravet oppfylles ikke). Det skal i tillegg gis en beskrivelse av hvordan kravet oppfylles, eller når kravet kan bli oppfylt i fremtiden. Funksjonaliteten ift bør-kravene benyttes i rangeringen av løsningene. 2.2 FUNKSJONELLE KRAV Verktøyet skal ha flere bruksnivåer, med ulike behov: - Enkel bruk: Innebærer bruk av ferdige rapporter/dashbord med kun muligheter for å gjøre foreta utvalg (for eksempel å velge år/semester, fakultet/avdeling). - Rapportutvikling: Utvikling av nye rapporter/dashbord/portaler - Administrasjon og installasjon: Installasjon av verktøyet, administrasjon av brukere/roller, oppsett av sluttbrukerlag 2.3 OVERORDNETE KRAV Her beskrives generelle krav og krav til støtte for hovedfunksjoner. Hovedfunksjoner er rapporter og visualisering i systemet. 2.3.1 Verktøyet skal være et standardsystem, Med standardsystem mener vi ferdigutviklede systemer. Standardsystemer kan bestå av ulike moduler som kan berike funksjonalitet, utvide grensesnitt og annet. Det skal gis en tydelig beskrivelse av hvilke elementer som inngår i tilbudet og hvilke elementer eller moduler som kan anskaffes i tillegg. 2.3.2 Verktøyet må kunne håndtere flere ulike juridiske enheter (institusjoner) Verktøyet må kunne brukes av flere institusjoner som kun har tilgang til institusjonens data og som hver har rettigheter til å opprette brukere, tildele roller og utvikle og distribuere rapporter for egen institusjon. Beskriv løsning. 2.3.3 Verktøyet skal ha funksjonalitet for å definere og visualisere rapporter. Rapportene skal enten bli tilgjengeliggjort som standardrapport for alle institusjoner, for en enkelt institusjon eller en enkelt sluttbruker/ gruppe av sluttbrukere. Beskriv løsning 2.3.4 Beskriv eventuell analysefunksjonalitet i verktøyet. 2.3.5 Verktøyet skal være rollebasert slik at det kan benyttes av ulike brukerkategorier, f.eks. sluttbrukere og superbrukere. Spesifiser løsning for brukeradministrasjon, opprettelse og administrering av roller, grupper m.m. 2.3.6 Verktøyet skal ha funksjonalitet for å vise rapporter på egne websider, portal, dashboard osv. Beskriv løsning. 3

2.4 KRAV TIL RAPPORTFUNKSJONALITET OG VISUALISERING I verktøyet skal det utvikles standardrapporter i tillegg til at den enkelte superbruker/utvikler skal kunne lage egne rapporter. Her beskrives krav til viktige egenskaper i forhold til rapportene. Krav til funksjoner for rapportgenerering og oppfølging Generell funksjonalitet: 2.4.1 I tilfeller der rapportenes forekomster blir 5 eller lavere, er ikke lenger dataene tilstrekkelig anonymisert og det blir behov for å ivareta dette. Beskriv verktøyets eventuelle mekanismer for anonymisering. Funksjonalitet for sluttbruker: 2.4.2 Verktøyet skal ha funksjonalitet for å få flere grafiske og tabellariske fremstillinger i samme oversiktsbilde. Beskriv løsning. 2.4.3 Verktøyet skal ha funksjonalitet å fremvise enkeltelementer i hovedtabellen, f. eks topp fem eller lignende. Beskriv løsning. 2.4.4 Verktøyet skal ha funksjonalitet for å generere aggregerte rapporter med drill-down-effekt. Beskriv løsning. 2.4.5 Verktøyet skal ha funksjonalitet for å lage formatterte rapporter og eksportere disse til Office og HTML. Beskriv løsning. 2.4.6 Verktøyet skal ha en løsning for å kunne bevare rapportens funksjoner (for eksempel filtrering, oppdatering av data med mer) etter eksport til andre standard programpakker som Office. Beskriv løsning. 2.4.7 Verktøyet skal ha et utvalg av diagramtyper. Beskriv utvalget. 2.4.8 Beskriv eventuell mulighet for å veksle mellom grafisk og tabell fremstilling. Funksjonalitet for superbruker/systemadministrator: 2.4.9 Superbruker/systemadministrator skal kunne velge om valgte filter skal vises for sluttbruker i overskriften i rapporten. Beskriv løsning. 2.4.10 Rapportgeneratoren må ha funksjon til å velge filter ved hjelp av enkle pek/ klikk eller rullegardinvalg for systemadministrator/superbruker. Dette må også være tilgjengelig for sluttbruker. Beskriv løsning. 2.4.11 Verktøyet skal ha funksjonalitet som gjør rapportenes SQL-kode tilgjengelig for superbruker/systemadministrator. Beskriv løsning. 2.4.12 Verktøyet skal ha funksjonalitet som gjør det mulig for superbruker/systemadministrator å endre rapportens SQL-kode. Beskriv løsning. 2.4.13 Det skal finnes et egnet felt hvor superbruker/systemadministrator kan legge inn beskrivelse av rapporter/dashbord som er tilgjengelig/leselig for sluttbruker. Beskriv løsning. 2.4.14 Tabellrelasjonene fra kilde som benyttes av verktøyet skal kunne vises og manipuleres i verktøyet av systemadministrator og superbruker. Beskriv løsning. 2.4.15 Verktøyet skal ha støtte for style sheets /maler, slik at rapporter får et standardisert utseende. Beskriv løsning. 2.4.16 Verktøyet skal vise hvilke rapporter/dashbord som er avhengig av et gitt felt (impact-analyse) og hvilke kolonner som er kilder til et element i en rapport/dashbord (data lineage). Beskriv løsning. 4

2.4.17 Verktøyet skal kunne schedulere rapporter og dashbord slik at man kan kjøre rapporter til fastsatte tider. Beskriv løsning. 2.4.18 Verktøyet skal kunne ta i bruk tabellrelasjonene fra kilde. Beskriv løsning. 2.4.19 Det må være mulig å dele lokalt utviklede rapportspørringer til andre institusjoner, slik at de kan benytte disse for sine institusjonsdata. Beskriv løsning for distribusjon. 5

2.5 KRAV TIL BRUKERGRENSESNITT (SØK, RAPPORTERING OG LOGGFUNKSJONALITET) Krav til egenskaper ved brukergrensesnittet Generell funksjonalitet: 2.5.1 Det skal finnes hjelpetekster i brukergrensesnittet ved utvikling av rapporter, administrasjon av verktøyet, brukergrensesnittet for sluttbruker m.m. på minimum engelsk, men det er ønskelig med norsk. Funksjonalitet for sluttbruker: 2.5.2 Verktøyet skal ha et Web-basert brukergrensesnitt for sluttbrukere. Beskriv løsningen. 2.5.3 Det er ønskelig at webgrensesnittet følger retningslinjene fra Web Accessibility Initiative (WAI). Tilbyder skal beskrive hvordan løsningen følger retningslinjene og dersom retningslinjene ikke følges 100% også beskrive planene for å bedre på dette. 2.5.4 Verktøyet skal ha en løsning for individuell konfigurering for sluttbruker (f.eks. for å gjøre lokale tilpasninger i sin arbeidsflate som kan lagres) Spesifiser og beskriv muligheter. 2.5.5 Verktøyet skal ha mulighet for søk i metadata og selve dataene. Søk i metadata er søk før man har kjørt rapporter, som hvilke rapporter finnes innenfor et gitt tema. Søk i selve dataene er søk etter at rapport er kjørt. Beskriv løsning. Funksjonalitet for superbruker/systemadministrator: 2.5.6 Design av rapportene for systemadministrator/superbruker må være skjermbasert, dra og slipp, fortrinnsvis syntaksfritt. Beskriv løsning. 2.5.7 Verktøyet skal kunne settes opp til å tilpasses ulike roller. Beskriv løsningen. 2.5.8 Verktøyet skal ha løsning for logg, spesielt med tanke for logg av responstider. Beskriv løsning. 2.5.9 Verktøyet skal ha en løsning for å legge inn egne hjelpetekster i rapporter/dashboards av systemadministrator/superbruker som kan benyttes av sluttbruker ved bruk av rapporter/dashboards. Beskriv løsning. 3 Krav til system- og brukeradministrasjon 3.1 KRAV TIL TILGANGSRETTIGHETER, ROLLER OG BRUKERE Rettigheter omfatter både funksjonsrettigheter (for eksempel retten til å kunne lage rapporter og hente ut datasett) og adgangsrettigheter (for eksempel retten til å lese data fra flere institusjoner). Funksjonsrettigheter styres på rollenivå. Adgangsrettigheter styres på brukernivå. Krav til tilgangskontroll og sikkerhet ID Krav Generell funksjonalitet: 6

ID Krav 3.1.1 Verktøyet skal ha funksjonalitet som ivaretar datasikkerhet og rutiner for å fange opp og korrigere eventuelle sikkerhetshull. Dokumenter verktøyets datasikkerhet. 3.1.2 Verktøyet skal ha en funksjonalitet for at all tilgang til verktøyets funksjoner reguleres gjennom en unik brukeridentitet og brukerprofil (inneholder for eksempel brukerrolle, org.tilhørighet). Beskriv løsning. 3.1.3 Verktøyet skal kunne støtte ekstern autentisering basert på protokoller for autentisering gitt i bilag 3, slik som FEIDE og MinID, evt. skal det kunne utvikle slik støtte. Beskriv løsning eller beskriv muligheter for å utvikle slik støtte hvor det sies noe om tid og kostnad for en slik utvikling. 3.1.4 Verktøyet må støtte ekstern autorisasjon basert på protokoller for autorisasjon gitt i bilag 3. Alternativt skal verktøyet støtte provisjonering av autorisasjonsdata basert på standardisert import av tilgangsdata gjerne via en WebService basert på SOAP. Beskriv løsning. 3.1.5 Sluttbruker skal kun ha tilgang til data for egen institusjon. Superbrukere skal kun ha tilganger innenfor egen institusjon og institusjoner det er avtalt å samarbeide om forvaltning med. Systemadministrator skal ha tilgang til data for de institusjonene de skal drive brukerstøtte for. Beskriv løsning. Funksjonalitet for superbruker/systemadministrator: 3.1.6 Verktøyet skal ha en løsning for håndtering av brukeradministrasjon og tilgang av systemadministrator/superbrukere i henhold til spesifikasjoner i bilag 3. Beskriv løsning. 3.1.7 Verktøyet skal ha funksjonalitet der roller og tilganger administreres med et GUI med for eksempel dra og slipp. Beskriv løsning. 3.1.8 Superbrukere skal kunne definere rapporter og gjøre disse tilgjengelig for andre brukere på sin institusjon. Beskriv løsning. 3.1.9 Rettigheter skal kunne kopieres eller arves mellom brukergrupper på ulikt nivå i hierarkiet. Beskriv hvordan dette løses, samt hvordan en rettighet kan overstyre en annen. Beskriv løsning. 3.1.10 Verktøyet skal ha funksjonalitet for å ta ut rapporter pr rolle og/eller institusjon, for å se hvilke rapporter som er knyttet til disse. Beskriv løsning. 3.1.11 Institusjonene skal selv kunne administrere tilgangskontroll på de forskjellige roller og nivåer på institusjonen. Systemadministrator skal ha tilgang til å gjøre dette for de institusjonene de skal ha brukerstøtte for. Beskriv løsning. 3.2 KRAV TIL SYSTEMKONFIGURASJON OG SYSTEMADMINISTRASJON Krav til systemkonfigurasjon og systemadministrasjon 3.2.1 Verktøyet må ha Unicode UTF8 støtte. Beskriv løsning. 3.2.2 Det skal være mulig å endre navn på felter som kommer fra kilde. Det må også være mulig for den enkelte institusjon å endre navn på slike felter i ettertid på rapporter slik at de kan tilpasses bedre den enkelte institusjon hvis dette er nødvendig. Beskriv løsning. 7

3.2.3 Det skal være mulig å definere faste tekster i rapportene, som for eks. overskrifter. Beskriv løsning. 3.2.4 Det skal være mulig å definere tilleggsfelter som f.eks. egne beregninger utover felter hentet fra kilde. Beskriv løsning. 3.2.5 Verktøyet skal ha funksjonalitet for automatisk avlogging av en bruker som har vært inaktiv i et definert antall minutter. Beskriv løsning. 3.2.6 Det er ønskelig å kunne parametersette hvor mange funn som kan vises pr. skjermbilde. Beskriv løsning. 3.3 YTELSE OG ANTALL BRUKERE Krav til ytelse og skalering 3.3.1 Verktøyet må ha en arkitektur som er i stand til å håndtere institusjonenes behov for bearbeiding av store datamengder og stort antall brukere i henhold til beskrivelser i bilag 3. Beskriv skaleringsmuligheter. 3.3.2 Verktøyet skal ha en high-availability-løsning som fungerer sammen med verktøyet. Beskriv løsning. 4 Tekniske krav til verktøyet 4.1 TEKNISKE KRAV, KLIENTER Krav til tekniske krav for klienter 4.1.1 Verktøyet skal ha en flerlagsarkitektur med et metadatalag som danner et felles grunnlag for brukere av rapporter/dashbord. Beskriv løsning. 4.1.2 Verktøyet må ha 0-klientversjon for sluttbrukere som bare skal kjøre ferdige rapporter (dvs. en browser-versjon). Beskriv løsning. 4.1.3 Verktøyet må ha en 0-klientversjon for superbrukere som skal utvikle rapporter (dvs. en browser-versjon). Jf. Bilag 3 Beskriv løsning. 4.1.4 Verktøyet skal ha støtte for lesetavle (tablet) med mer for å kunne lese/bruke ferdigutviklede rapporter/dashboards. Beskriv løsning. 4.1.5 All funksjonalitet i tjenesten skal minst støtte nettlesere gitt i bilag 3. Redegjør for rutiner for å sikre støtte til nyere versjoner når de kommer. 4.1.6 Websidene skal følge standarder for websider gitt i bilag 3. 4.1.7 Det skal være støtte for 64-bits arkitektur (gjelder applikasjonsserver). Beskriv løsning. 4.1.8 Beskriv løsning for cashing og in-memory-bruk (gjelder applikasjonsserver) 4.1.9 Repository/metadata og kildedata må kunne legges i database gitt i bilag 3. Beskriv løsning. 4.1.10 Verktøyet må kunne benytte VPD i database, se bilag 3, eller evt ha egen løsning for denne type håndtering. Beskriv løsning. 4.1.11 Applikasjonsserver må kunne bruke plattformer gitt i bilag 3. Beskriv løsning 4.1.12 Beskriv hvilke verktøy applikasjonsserver benytter som f. eks Resin, Apache, Jboss. Beskriv løsning. 4.1.13 IT-verktøyet må tillate bruk av brannmur. Beskriv løsning. 8

4.1.14 Verktøyet skal ha sikkerhetsmekanismer for kryptering av data. Beskriv løsning. Løsningen skal være i tråd med kravene beskrevet i Bilag 3. 4.2 GRENSESNITT Krav til grensesnitt mot andre systemer med de presiseringer som er gitt i bilag 3. 4.2.1 Beskriv muligheter for grensesnitt mot epostsystem. 4.2.2 Verktøyet må kunne lese fra Oracle-kilder 4.2.3 Verktøyet skal kunne lese de vanligste og mest utbredte kilder slik som PostGreSQL, SQLserver, MySQL og tekstfiler. Beskriv hvilke kilder man kan lese data fra. 4.2.4 Verktøyet skal ha løsning for kommunikasjon med en database. Beskriv løsning (er det applikasjonsserver som kommuniserer med databasen, tykkklient osv.). 5 IKT-arkitektur 5.1 FELLES IKT-ARKITEKTUR Gjeldende faktaark med Prinsipp for planlegging av IKT-løysinger (se vedlegg) er en sjekkliste for generelle arkitekturkrav som bør oppfylles. Vi mener selv at vi har stilt de kravene som trengs for å fylle disse kravene. Disse kravene benyttes som kvalitetssikring slik at vi vet at vi har stilt de relevante kravene for å ivareta disse. 5.2 DRIFTSMESSIGE FORHOLD Krav til støtte for driftsmessige forhold 5.2.1 Alle endringer i IT-verktøyet må skje kontrollert og gjøres til gjenstand for sikkerhetsmessig godkjenning og testing. Leverandøren må kunne vise til rutiner for systemvedlikehold og oppgraderinger. Oppgraderinger som Leverandøren leverer vil Kunden selv installere i testversjon, foreta verifisering før det settes i produksjon. Beskriv rutiner knyttet til levering av oppgradering og programvarevedlikehold. 5.2.2 Verktøyet skal ha funksjonalitet for oppgradering. Beskriv løsning. 5.2.3 Beskriv løsning for oppgraderinger som kan foretas når verktøyet er oppe. 5.2.4 Oppgraderinger må kunne gjøres av kundens systemadministrator og kundens driftsorganisasjon. Beskriv løsning. 9

5.2.5 Beskriv teknisk spesifikasjon og krav til miljøene som kunden skal benytte til å drifte, utvikle/vedlikeholde/teste verktøyet og rapporter i henhold beskrivelser i Bilag 3 alternativ 1 og 2. Beskriv også rutiner for produksjonssetting av rapporter i henhold til alternativ 1 og 2 i Bilag 3. 5.2.6 For alle passord mellom applikasjonsserver og andre grensesnitt som f. eks databaser hvor passord er tatt i bruk, må passord kunne endres. Beskriv løsning. 5.2.7 Beskriv håndtering av passord i verktøyet. 5.2.8 Beskriv løsning for drift av brukeradministrasjon, samt hvordan testing og produksjonssetting kan være adskilt. 6 Krav i forbindelse med tjenesteleveransen Tjenesteleveransen ift denne kontrakten skal bestå av opplæring, bistand til test, konfigurering og dokumentasjon. Krav til tjenesteleveranse 6.0 Omfanget av nødvendig tjenesteleveranse må beskrives. Leverandøren skal utarbeide en detaljert plan som viser deres bistand i forbindelse med implementering og testing, jfr bilag 5 slik at milepælene i bilag 4 nås innen avtalte tider. Planen skal vise hvilke ressurser leverandøren deltar med og omfanget. 6.1 Timeprisen for konsulenter skal være iht. kompetansenivå. Jf bilag 7. 6.2 CV eller andre opplysninger vedr kvalifikasjoner til det personell som skal benyttes i leveransen skal være tilgjengelig for oppdragsgiver. Oppdragsgiver forbeholder seg retten til å godkjenne bruken av konsulenter. 6.3 Leverandør plikter å opprettholde tilbudt kompetansenivå og det antallet ressurser som er nødvendig for å gjennomføre leveransen uavhengig av bytte av konsulenter, ferieavvikling, permisjoner, sykdom m.m. 6.4 Det skal leveres terminvise timelister per konsulent, som i detalj viser hva som er gjort. 6.5 Det skal foretas kompetanseoverføring til institusjonsrepresentanter/ekspertgruppe, driftspersonell og systemadministratorer. Beskriv løsning. Beskriv kostnader i bilag 7. 6.6 Hver institusjon skal kunne kjøpe ekstra lisenser. Pris for ekstra lisenser utenom definert brukeromfang må spesifiseres av leverandør. Se bilag 3. 6.7 Omfanget av tjenesteleveranser skal være godkjent av kunden før igangsetting 6.8 Det skal beskrives rutiner knyttet til henvendelser og oppfølging i forbindelse med eventuell benyttelse av opsjoner for å ta i bruk verktøyet til andre systemer enn FS 10

7 Merkantile krav Merkantile krav 7.1 Prismodellen for tilbudte verktøy må inkludere alle produkter, tjenester, lisenser, utvikling/tilpasning, installasjon osv. som er nødvendig for at verktøyet kan implementeres iht. leverandørens løsningsbeskrivelse. 7.2 Lisensbestemmelser skal være faste i avtaleperioden, og være vedlagt til Avtalen. 7.3 Leverandørens målemetodikker for oppdragsgivers bruk av tilbudte lisenser må foreligge. 7.4 Leverandørens lisensbestemmelser i forbindelse med test, utvikling, recovery, standby osv. må foreligge. 7.5 Detaljert beskrivelse av Leverandørens support & vedlikeholdsbetingelser, inkl tilgjengelig supportapparat og supportnivå inkl priser for de forskjellige supportnivåene pr lisenstype må foreligge 7.6 Leverandøren skal vedlegge sin generelle vedlikeholdsavtale som supplement til bekreftelsene av det innhold i vedlikeholdsansvar som er gitt som bekreftelser og beskrivelser i punkt 8 under. 7.7 Spesifikasjon av opplæring inkl priser skal fremkomme. 7.8 Alle priser skal oppgis i NOK 7. 9 Betaling inntrer når Fase 1 er ferdig og leveransen er godkjent, se betalingsplan i bilag 7 7.10 Tilleggstjenester faktureres kun på bakgrunn av bestilling fra kunde, og skal alltid medføre en endringsordre fra kunde. En hver endring skal være skriftlig kontraktsfestet. 8 Krav til vedlikeholdsavtale/support Id Krav 8.1 Teknisk, funksjonell og Best-Practice support for driftspersonell og systemadministratorer. Beskriv tjenesten, inklusive rutiner for henvendelse og svartider, og gi pris på denne type support. 8.2 Beskriv innhold og omfang i tilbudt support og vedlikeholdsavtale. Beskrivelsen må inneholde informasjon om rutiner for melding av feil og videre oppfølging fra leverandørens side, herunder responstider og forventede rettetider ved forskjellige feil. Det må også beskrives hvilke rutiner leverandøren har for å varsle kunden om feil og mangler som oppdages i løsningen. Besvarelsen skal også inneholde en overordnet beskrivelse av supportorganisasjonen og hvor den er lokalisert. 8.3 Vedlikeholdsavtalen skal omfatte og inkludere feilrettinger, oppgraderinger og nye versjoner av verktøyet. Disse skal gjøres tilgjengelig for kunden uten unødig forsinkelse under forutsetning av at kunden har gyldig serviceavtale 11

med priser som er angitt i bilag 7. Leverandøren må beskrive rutiner for varsling og metoder for tilgjengeliggjøring av feilrettinger, oppgraderinger og nye versjoner. 8.4 Leverandøren forplikter seg til å yte vedlikehold i systemets levetid. Vedlikeholdet er løpende og fornyes automatisk, med mindre kunden sier det opp med 3 måneders varsel. 9 Opplæring, kursing og dokumentasjon (Avtalen punkt 2.1.2 Opplæring og avtalen punkt 2.1.1 Dokumentasjons og opplysningsplikt) Krav til brukerdokumentasjon og veiledningsmateriell Id Krav 9.1 All dokumentasjon ment for sluttbrukere skal være skrevet på norsk/engelsk. Dokumentasjon som kun er ment for superbrukere og teknisk personell kan være skrevet på engelsk. Beskriv tilgjengelige utførelser og formater for dokumentasjonen. 9.2 Det skal finnes komplett, detaljert, oppdatert brukerdokumentasjon i tillegg til oversiktlig og lettfattet brukerveiledning til verktøyet. Det er tilstrekkelig at dokumentasjonen gjøres tilgjengelig for kunden elektronisk. Oppdatering av dokumentasjonen skal helst foreligge før installasjon i kundens test, og helst 3 uker før endringer i tjenesten settes i produksjon. 9.3 Det skal være enkelt å skrive ut brukerdokumentasjon for både enkeltfunksjonalitet, og hele moduler / funksjonalitetsgrupper samlet. Utskrift av dokumentasjonen må danne et brukervennlig og pedagogisk alternativ for alle brukergrupper. 9.4 Det skal finnes en hjelpefunksjon tilrettelagt for søk etter et spesielt tema. Beskriv hvordan dette fungerer. 9.5 Det skal finnes rutiner for dokumentasjon av funksjonalitetsendringer av verktøyet. Beskriv rutinene. Krav til opplæring Id Krav 9.6 Det skal være mulig å benytte seg av leverandørens opplæringstilbud i hele avtaleperioden. Opplæring kan ytes til personer med drifts-, opplærings- og forvaltningsoppgaver hos kunden. Beskriv hvorledes opplæringsaktiviteter kan koordineres, gjennomføres og prises. 9.7 Det er ønskelig med mulighet for nettbasert opplæring som e-læring. Beskriv opplæringstyper med eventuelle påbyggingsmoduler. 9.8 Det må være en supportorganisasjon. Beskriv denne. 10 Krav til bistand etter godkjenning Det er viktig å sikre at kunden får den støtte til implementering av verktøyet som behøves i forhold til tidsplan, verktøyets hensikt og evt. behov for prosessendringer. 10.1 KONSULENTBISTAND OG OPPDRAG 12

Leverandøren skal på forespørsel og etter egen avtale yte kunden bistand til: - Bistand til optimalisering av kundens drift - Bistand Videreutvikling av kundenes felles driftsløsning av verktøyet - Kundespesifikke resultat av bistand og oppdrag med unntak av eventuell testing og implementering, skal gjøres tilgjengelig for Samarbeidstiltaket FS - Andre institusjoner og andre felles tiltak i sektoren skal ha opsjon på å kunne ta i bruk verktøyet. Denne avtalen med avtalte rammer og enhetspriser vil ligge til grunn for slike leveranser. Konkret vil det måtte etableres nye versjoner av bilag 4, samt presisering av omfang, det vil si kostnader og betaling 13

Bilag 2 Leverandørens løsningsspesifikasjon Leverandøren skal beskrive sin løsning i forhold til Kundens kravspesifikasjon i bilaget. Dette gjøres normalt ved at Leverandøren besvarer Kundens kravspesifikasjon punkt for punkt. Behov for oppgradering av Kundens tekniske plattform: (Dersom slik oppgradering er nødvendig for å utnytte leveransen skal Leverandøren påpeke dette her) Åpenbare feil, mangler eller uklarheter i Kundens kravspesifikasjon: (Dersom det er slike åpenbare feil, mangler eller uklarheter i Kundens kravspesifikasjon skal Leverandøren påpeke disse) Målet med avtalen: Avtalen omhandler et verktøy som fremstår som en rapport- og presentasjonsløsning. Overordnet funksjonalitet kan karakteriseres ved: - Rapportene vil inneholde styringsdata på utdanningsområdet på en visualisert måte. - Vise standardrapporter og tilrettelegger for kundens behov for egendefinerte rapporter og ad hoc-rapporter. - er tilrettelagt for kobling og bruk mot flere typer datakilder (kildesystem og datavarehus) Verktøyet skal være en rapport- og presentasjonsløsning som: - På en effektiv og brukervennlig måte støtter institusjonenes behov for data på utdanningsområdet - Tilbyr standardrapporter og tilrettelegger for institusjonenes behov for egendefinerte rapporter - Gir støtte for kontrollrapporter for bedret datakvalitet Leverandøren skal på en overordnet måte beskrive hvorledes verktøyet bidrar til å nå disse målene. 14

2.3-OVERORDNETE KRAV Her beskrives generelle krav og krav til støtte for hovedfunksjoner. Hovedfunksjoner er rapporter og visualisering i systemet. 2.3.1 Verktøyet skal være et standardsystem, Med standardsystem mener vi ferdigutviklede systemer. Standardsystemer kan bestå av ulike moduler som kan berike funksjonalitet, utvide grensesnitt og annet. Det skal gis en tydelig beskrivelse av hvilke elementer som inngår i tilbudet og hvilke elementer eller moduler som kan anskaffes i tillegg. 2.3.2 Verktøyet må kunne håndtere flere ulike juridiske enheter (institusjoner) Verktøyet må kunne brukes av flere institusjoner som kun har tilgang til institusjonens data og som hver har rettigheter til å opprette brukere, tildele roller og utvikle og distribuere rapporter for egen institusjon. Beskriv løsning. 2.3.3 Verktøyet skal ha funksjonalitet for å definere og visualisere rapporter. Rapportene skal enten bli tilgjengeliggjort som standardrapport for alle institusjoner, for en enkelt institusjon eller en enkelt sluttbruker/ gruppe av sluttbrukere. Beskriv løsning 2.3.4 Beskriv eventuell analysefunksjonalitet i verktøyet. 2.3.5 Verktøyet skal være rollebasert slik at det kan benyttes av ulike brukerkategorier, f.eks. sluttbrukere og superbrukere. Spesifiser løsning for brukeradministrasjon, opprettelse og administrering av roller, grupper m.m. 2.3.6 Verktøyet skal ha funksjonalitet for å vise rapporter på egne websider, portal, dashboard osv. Beskriv løsning. 2.4-KRAV TIL RAPPORTFUNKSJONALITET OG VISUALISERING I verktøyet skal det utvikles standardrapporter i tillegg til at den enkelte superbruker/utvikler skal kunne lage egne rapporter. Her beskrives krav til viktige egenskaper i forhold til rapportene. Krav til funksjoner for rapportgenerering og oppfølging Generell funksjonalitet: 2.4.1 I tilfeller der rapportenes forekomster blir 5 eller lavere, er ikke lenger dataene tilstrekkelig anonymisert og det blir behov for å ivareta dette. Beskriv verktøyets eventuelle mekanismer for anonymisering. Funksjonalitet for sluttbruker: 2.4.2 Verktøyet skal ha funksjonalitet for å få flere grafiske og tabellariske fremstillinger i samme oversiktsbilde. Beskriv løsning. 2.4.3 Verktøyet skal ha funksjonalitet å fremvise enkeltelementer i hovedtabellen, f. eks topp fem eller lignende. Beskriv løsning. 2.4.4 Verktøyet skal ha funksjonalitet for å generere aggregerte rapporter med drill-down-effekt. Beskriv løsning. 2.4.5 Verktøyet skal ha funksjonalitet for å lage formatterte rapporter og eksportere disse til Office og HTML. Beskriv løsning. 15

2.4.6 Verktøyet skal ha en løsning for å kunne bevare rapportens funksjoner (for eksempel filtrering, oppdatering av data med mer) etter eksport til andre standard programpakker som Office. Beskriv løsning. 2.4.7 Verktøyet skal ha et utvalg av diagramtyper. Beskriv utvalget. 2.4.8 Beskriv eventuell mulighet for å veksle mellom grafisk og tabell fremstilling. Funksjonalitet for superbruker/systemadministrator: 2.4.9 Superbruker/systemadministrator skal kunne velge om valgte filter skal vises for sluttbruker i overskriften i rapporten. Beskriv løsning. 2.4.10 Rapportgeneratoren må ha funksjon til å velge filter ved hjelp av enkle pek/ klikk eller rullegardinvalg for systemadministrator/superbruker. Dette må også være tilgjengelig for sluttbruker. Beskriv løsning. 2.4.11 Verktøyet skal ha funksjonalitet som gjør rapportenes SQL-kode tilgjengelig for superbruker/systemadministrator. Beskriv løsning. 2.4.12 Verktøyet skal ha funksjonalitet som gjør det mulig for superbruker/systemadministrator å endre rapportens SQL-kode. Beskriv løsning. 2.4.13 Det skal finnes et egnet felt hvor superbruker/systemadministrator kan legge inn beskrivelse av rapporter/dashbord som er tilgjengelig/leselig for sluttbruker. Beskriv løsning. 2.4.14 Tabellrelasjonene fra kilde som benyttes av verktøyet skal kunne vises og manipuleres i verktøyet av systemadministrator og superbruker. Beskriv løsning. 2.4.15 Verktøyet skal ha støtte for style sheets /maler, slik at rapporter får et standardisert utseende. Beskriv løsning. 2.4.16 Verktøyet skal vise hvilke rapporter/dashbord som er avhengig av et gitt felt (impact-analyse) og hvilke kolonner som er kilder til et element i en rapport/dashbord (data lineage). Beskriv løsning. 2.4.17 Verktøyet skal kunne schedulere rapporter og dashbord slik at man kan kjøre rapporter til fastsatte tider. Beskriv løsning. 2.4.18 Verktøyet skal kunne ta i bruk tabellrelasjonene fra kilde. Beskriv løsning. 2.4.19 Det må være mulig å dele lokalt utviklede rapportspørringer til andre institusjoner, slik at de kan benytte disse for sine institusjonsdata. Beskriv løsning for distribusjon. 16

2.5-KRAV TIL BRUKERGRENSESNITT (SØK, RAPPORTERING OG LOGGFUNKSJONALITET) Krav til egenskaper ved brukergrensesnittet Generell funksjonalitet: 2.5.1 Det skal finnes hjelpetekster i brukergrensesnittet ved utvikling av rapporter, administrasjon av verktøyet, brukergrensesnittet for sluttbruker m.m. på minimum engelsk, men det er ønskelig med norsk. Funksjonalitet for sluttbruker: 2.5.2 Verktøyet skal ha et Web-basert brukergrensesnitt for sluttbrukere. Beskriv løsningen. 2.5.3 Det er ønskelig at webgrensesnittet følger retningslinjene fra Web Accessibility Initiative (WAI). Tilbyder skal beskrive hvordan løsningen følger retningslinjene og dersom retningslinjene ikke følges 100% også beskrive planene for å bedre på dette. 2.5.4 Verktøyet skal ha en løsning for individuell konfigurering for sluttbruker (f.eks. for å gjøre lokale tilpasninger i sin arbeidsflate som kan lagres) Spesifiser og beskriv muligheter. 2.5.5 Verktøyet skal ha mulighet for søk i metadata og selve dataene. Søk i metadata er søk før man har kjørt rapporter, som hvilke rapporter finnes innenfor et gitt tema. Søk i selve dataene er søk etter at rapport er kjørt. Beskriv løsning. Funksjonalitet for superbruker/systemadministrator: 2.5.6 Design av rapportene for systemadministrator/superbruker må være skjermbasert, dra og slipp, fortrinnsvis syntaksfritt. Beskriv løsning. 2.5.7 Verktøyet skal kunne settes opp til å tilpasses ulike roller. Beskriv løsningen. 2.5.8 Verktøyet skal ha løsning for logg, spesielt med tanke for logg av responstider. Beskriv løsning. 2.5.9 Verktøyet skal ha en løsning for å legge inn egne hjelpetekster i rapporter/dashboards av systemadministrator/superbruker som kan benyttes av sluttbruker ved bruk av rapporter/dashboards. Beskriv løsning. 3-Krav til system- og brukeradministrasjon 3.1-KRAV TIL TILGANGSRETTIGHETER, ROLLER OG BRUKERE Rettigheter omfatter både funksjonsrettigheter (for eksempel retten til å kunne lage rapporter og hente ut datasett) og adgangsrettigheter (for eksempel retten til å lese data fra flere institusjoner). Funksjonsrettigheter styres på rollenivå. Adgangsrettigheter styres på brukernivå. Krav til tilgangskontroll og sikkerhet ID Krav Generell funksjonalitet: 17

ID Krav 3.1.1 Verktøyet skal ha funksjonalitet som ivaretar datasikkerhet og rutiner for å fange opp og korrigere eventuelle sikkerhetshull. Dokumenter verktøyets datasikkerhet. 3.1.2 Verktøyet skal ha en funksjonalitet for at all tilgang til verktøyets funksjoner reguleres gjennom en unik brukeridentitet og brukerprofil (inneholder for eksempel brukerrolle, org.tilhørighet). Beskriv løsning. 3.1.3 Verktøyet skal kunne støtte ekstern autentisering basert på protokoller for autentisering gitt i bilag 3, slik som FEIDE og MinID, evt. skal det kunne utvikle slik støtte. Beskriv løsning eller beskriv muligheter for å utvikle slik støtte hvor det sies noe om tid og kostnad for en slik utvikling. 3.1.4 Verktøyet må støtte ekstern autorisasjon basert på protokoller for autorisasjon gitt i bilag 3. Alternativt skal verktøyet støtte provisjonering av autorisasjonsdata basert på standardisert import av tilgangsdata gjerne via en WebService basert på SOAP. Beskriv løsning. 3.1.5 Sluttbruker skal kun ha tilgang til data for egen institusjon. Superbrukere skal kun ha tilganger innenfor egen institusjon og institusjoner det er avtalt å samarbeide om forvaltning med. Systemadministrator skal ha tilgang til data for de institusjonene de skal drive brukerstøtte for. Beskriv løsning. Funksjonalitet for superbruker/systemadministrator: 3.1.6 Verktøyet skal ha en løsning for håndtering av brukeradministrasjon og tilgang av systemadministrator/superbrukere i henhold til spesifikasjoner i bilag 3. Beskriv løsning. 3.1.7 Verktøyet skal ha funksjonalitet der roller og tilganger administreres med et GUI med for eksempel dra og slipp. Beskriv løsning. 3.1.8 Superbrukere skal kunne definere rapporter og gjøre disse tilgjengelig for andre brukere på sin institusjon. Beskriv løsning. 3.1.9 Rettigheter skal kunne kopieres eller arves mellom brukergrupper på ulikt nivå i hierarkiet. Beskriv hvordan dette løses, samt hvordan en rettighet kan overstyre en annen. Beskriv løsning. 3.1.10 Verktøyet skal ha funksjonalitet for å ta ut rapporter pr rolle og/eller institusjon, for å se hvilke rapporter som er knyttet til disse. Beskriv løsning. 3.1.11 Institusjonene skal selv kunne administrere tilgangskontroll på de forskjellige roller og nivåer på institusjonen. Systemadministrator skal ha tilgang til å gjøre dette for de institusjonene de skal ha brukerstøtte for. Beskriv løsning. 3.2-KRAV TIL SYSTEMKONFIGURASJON OG SYSTEMADMINISTRASJON Krav til systemkonfigurasjon og systemadministrasjon 3.2.1 Verktøyet må ha Unicode UTF8 støtte. Beskriv løsning. 3.2.2 Det skal være mulig å endre navn på felter som kommer fra kilde. Det må også være mulig for den enkelte institusjon å endre navn på slike felter i ettertid på rapporter slik at de kan tilpasses bedre den enkelte institusjon hvis dette er nødvendig. Beskriv løsning. 18

3.2.3 Det skal være mulig å definere faste tekster i rapportene, som for eks. overskrifter. Beskriv løsning. 3.2.4 Det skal være mulig å definere tilleggsfelter som f.eks. egne beregninger utover felter hentet fra kilde. Beskriv løsning. 3.2.5 Verktøyet skal ha funksjonalitet for automatisk avlogging av en bruker som har vært inaktiv i et definert antall minutter. Beskriv løsning. 3.2.6 Det er ønskelig å kunne parametersette hvor mange funn som kan vises pr. skjermbilde. Beskriv løsning. 3.3-YTELSE OG ANTALL BRUKERE Krav til ytelse og skalering 3.3.1 Verktøyet må ha en arkitektur som er i stand til å håndtere institusjonenes behov for bearbeiding av store datamengder og stort antall brukere i henhold til beskrivelser i bilag 3. Beskriv skaleringsmuligheter. 3.3.2 Verktøyet skal ha en high-availability-løsning som fungerer sammen med verktøyet. Beskriv løsning. 4-Tekniske krav til verktøyet 4.1-TEKNISKE KRAV, KLIENTER Krav til tekniske krav for klienter 4.1.1 Verktøyet skal ha en flerlagsarkitektur med et metadatalag som danner et felles grunnlag for brukere av rapporter/dashbord. Beskriv løsning. 4.1.2 Verktøyet må ha 0-klientversjon for sluttbrukere som bare skal kjøre ferdige rapporter (dvs. en browser-versjon). Beskriv løsning. 4.1.3 Verktøyet må ha en 0-klientversjon for superbrukere som skal utvikle rapporter (dvs. en browser-versjon). Jf. Bilag 3 Beskriv løsning. 4.1.4 Verktøyet skal ha støtte for lesetavle (tablet) med mer for å kunne lese/bruke ferdigutviklede rapporter/dashboards. Beskriv løsning. 4.1.5 All funksjonalitet i tjenesten skal minst støtte nettlesere gitt i bilag 3. Redegjør for rutiner for å sikre støtte til nyere versjoner når de kommer. 4.1.6 Websidene skal følge standarder for websider gitt i bilag 3. 4.1.7 Det skal være støtte for 64-bits arkitektur (gjelder applikasjonsserver). Beskriv løsning. 4.1.8 Beskriv løsning for cashing og in-memory-bruk (gjelder applikasjonsserver) 4.1.9 Repository/metadata og kildedata må kunne legges i database gitt i bilag 3. Beskriv løsning. 4.1.10 Verktøyet må kunne benytte VPD i database, se bilag 3, eller evt ha egen løsning for denne type håndtering. Beskriv løsning. 4.1.11 Applikasjonsserver må kunne bruke plattformer gitt i bilag 3. Beskriv løsning 4.1.12 Beskriv hvilke verktøy applikasjonsserver benytter som f. eks Resin, Apache, Jboss. Beskriv løsning. 4.1.13 IT-verktøyet må tillate bruk av brannmur. Beskriv løsning. 19

4.1.14 Verktøyet skal ha sikkerhetsmekanismer for kryptering av data. Beskriv løsning. Løsningen skal være i tråd med kravene beskrevet i Bilag 3. 4.2-GRENSESNITT Krav til grensesnitt mot andre systemer med de presiseringer som er gitt i bilag 3. 4.2.1 Beskriv muligheter for grensesnitt mot epostsystem. 4.2.2 Verktøyet må kunne lese fra Oracle-kilder 4.2.3 Verktøyet skal kunne lese de vanligste og mest utbredte kilder slik som PostGreSQL, SQLserver, MySQL og tekstfiler. Beskriv hvilke kilder man kan lese data fra. 4.2.4 Verktøyet skal ha løsning for kommunikasjon med en database. Beskriv løsning (er det applikasjonsserver som kommuniserer med databasen, tykkklient osv.). 5-IKT-arkitektur 5.1-FELLES IKT-ARKITEKTUR Gjeldende faktaark med Prinsipp for planlegging av IKT-løysinger (se vedlegg) er en sjekkliste for generelle arkitekturkrav som bør oppfylles. Vi mener selv at vi har stilt de kravene som trengs for å fylle disse kravene. Disse kravene benyttes som kvalitetssikring slik at vi vet at vi har stilt de relevante kravene for å ivareta disse. 5.2-DRIFTSMESSIGE FORHOLD Krav til støtte for driftsmessige forhold 5.2.1 Alle endringer i IT-verktøyet må skje kontrollert og gjøres til gjenstand for sikkerhetsmessig godkjenning og testing. Leverandøren må kunne vise til rutiner for systemvedlikehold og oppgraderinger. Oppgraderinger som Leverandøren leverer vil Kunden selv installere i testversjon, foreta verifisering før det settes i produksjon. Beskriv rutiner knyttet til levering av oppgradering og programvarevedlikehold. 5.2.2 Verktøyet skal ha funksjonalitet for oppgradering. Beskriv løsning. 5.2.3 Beskriv løsning for oppgraderinger som kan foretas når verktøyet er oppe. 5.2.4 Oppgraderinger må kunne gjøres av kundens systemadministrator og kundens driftsorganisasjon. Beskriv løsning. 20

5.2.5 Beskriv teknisk spesifikasjon og krav til miljøene som kunden skal benytte til å drifte, utvikle/vedlikeholde/teste verktøyet og rapporter i henhold beskrivelser i Bilag 3 alternativ 1 og 2. Beskriv også rutiner for produksjonssetting av rapporter i henhold til alternativ 1 og 2 i Bilag 3. 5.2.6 For alle passord mellom applikasjonsserver og andre grensesnitt som f. eks databaser hvor passord er tatt i bruk, må passord kunne endres. Beskriv løsning. 5.2.7 Beskriv håndtering av passord i verktøyet. 5.2.8 Beskriv løsning for drift av brukeradministrasjon, samt hvordan testing og produksjonssetting kan være adskilt. 6-Krav i forbindelse med tjenesteleveransen Tjenesteleveransen ift denne kontrakten skal bestå av opplæring, bistand til test, konfigurering og dokumentasjon. Krav til tjenesteleveranse 6.0 Omfanget av nødvendig tjenesteleveranse må beskrives. Leverandøren skal utarbeide en detaljert plan som viser deres bistand i forbindelse med implementering og testing, jfr bilag 5 slik at milepælene i bilag 4 nås innen avtalte tider. Planen skal vise hvilke ressurser leverandøren deltar med og omfanget. 6.1 Timeprisen for konsulenter skal være iht. kompetansenivå. Jf bilag 7. 6.2 CV eller andre opplysninger vedr kvalifikasjoner til det personell som skal benyttes i leveransen skal være tilgjengelig for oppdragsgiver. Oppdragsgiver forbeholder seg retten til å godkjenne bruken av konsulenter. 6.3 Leverandør plikter å opprettholde tilbudt kompetansenivå og det antallet ressurser som er nødvendig for å gjennomføre leveransen uavhengig av bytte av konsulenter, ferieavvikling, permisjoner, sykdom m.m. 6.4 Det skal leveres terminvise timelister per konsulent, som i detalj viser hva som er gjort. 6.5 Det skal foretas kompetanseoverføring til institusjonsrepresentanter/ekspertgruppe, driftspersonell og systemadministratorer. Beskriv løsning. Beskriv kostnader i bilag 7. 6.6 Hver institusjon skal kunne kjøpe ekstra lisenser. Pris for ekstra lisenser utenom definert brukeromfang må spesifiseres av leverandør. Se bilag 3. 6.7 Omfanget av tjenesteleveranser skal være godkjent av kunden før igangsetting 6.8 Det skal beskrives rutiner knyttet til henvendelser og oppfølging i forbindelse med eventuell benyttelse av opsjoner for å ta i bruk verktøyet til andre systemer enn FS 21

7-Merkantile krav Merkantile krav 7.1 Prismodellen for tilbudte verktøy må inkludere alle produkter, tjenester, lisenser, utvikling/tilpasning, installasjon osv. som er nødvendig for at verktøyet kan implementeres iht. leverandørens løsningsbeskrivelse. 7.2 Lisensbestemmelser skal være faste i avtaleperioden, og være vedlagt til Avtalen. 7.3 Leverandørens målemetodikker for oppdragsgivers bruk av tilbudte lisenser må foreligge. 7.4 Leverandørens lisensbestemmelser i forbindelse med test, utvikling, recovery, standby osv. må foreligge. 7.5 Detaljert beskrivelse av Leverandørens support & vedlikeholdsbetingelser, inkl tilgjengelig supportapparat og supportnivå inkl priser for de forskjellige supportnivåene pr lisenstype må foreligge 7.6 Leverandøren skal vedlegge sin generelle vedlikeholdsavtale som supplement til bekreftelsene av det innhold i vedlikeholdsansvar som er gitt som bekreftelser og beskrivelser i punkt 8 under. 7.7 Spesifikasjon av opplæring inkl priser skal fremkomme. 7.8 Alle priser skal oppgis i NOK 7. 9 Betaling inntrer når Fase 1 er ferdig og leveransen er godkjent, se betalingsplan i bilag 7 7.10 Tilleggstjenester faktureres kun på bakgrunn av bestilling fra kunde, og skal alltid medføre en endringsordre fra kunde. En hver endring skal være skriftlig kontraktsfestet. 8-Krav til vedlikeholdsavtale/support Id Krav 8.1 Teknisk, funksjonell og Best-Practice support for driftspersonell og systemadministratorer. Beskriv tjenesten, inklusive rutiner for henvendelse og svartider, og gi pris på denne type support. 8.2 Beskriv innhold og omfang i tilbudt support og vedlikeholdsavtale. Beskrivelsen må inneholde informasjon om rutiner for melding av feil og videre oppfølging fra leverandørens side, herunder responstider og forventede rettetider ved forskjellige feil. Det må også beskrives hvilke rutiner leverandøren har for å varsle kunden om feil og mangler som oppdages i løsningen. Besvarelsen skal også inneholde en overordnet beskrivelse av supportorganisasjonen og hvor den er lokalisert. 8.3 Vedlikeholdsavtalen skal omfatte og inkludere feilrettinger, oppgraderinger og 22

nye versjoner av verktøyet. Disse skal gjøres tilgjengelig for kunden uten unødig forsinkelse under forutsetning av at kunden har gyldig serviceavtale med priser som er angitt i bilag 7. Leverandøren må beskrive rutiner for varsling og metoder for tilgjengeliggjøring av feilrettinger, oppgraderinger og nye versjoner. 8.4 Leverandøren forplikter seg til å yte vedlikehold i systemets levetid. Vedlikeholdet er løpende og fornyes automatisk, med mindre kunden sier det opp med 3 måneders varsel. 9-Opplæring, kursing og dokumentasjon (Avtalen punkt 2.1.2 Opplæring og avtalen punkt 2.1.1 Dokumentasjons og opplysningsplikt) Krav til brukerdokumentasjon og veiledningsmateriell Id Krav 9.1 All dokumentasjon ment for sluttbrukere skal være skrevet på norsk/engelsk. Dokumentasjon som kun er ment for superbrukere og teknisk personell kan være skrevet på engelsk. Beskriv tilgjengelige utførelser og formater for dokumentasjonen. 9.2 Det skal finnes komplett, detaljert, oppdatert brukerdokumentasjon i tillegg til oversiktlig og lettfattet brukerveiledning til verktøyet. Det er tilstrekkelig at dokumentasjonen gjøres tilgjengelig for kunden elektronisk. Oppdatering av dokumentasjonen skal helst foreligge før installasjon i kundens test, og helst 3 uker før endringer i tjenesten settes i produksjon. 9.3 Det skal være enkelt å skrive ut brukerdokumentasjon for både enkeltfunksjonalitet, og hele moduler / funksjonalitetsgrupper samlet. Utskrift av dokumentasjonen må danne et brukervennlig og pedagogisk alternativ for alle brukergrupper. 9.4 Det skal finnes en hjelpefunksjon tilrettelagt for søk etter et spesielt tema. Beskriv hvordan dette fungerer. 9.5 Det skal finnes rutiner for dokumentasjon av funksjonalitetsendringer av verktøyet. Beskriv rutinene. Krav til opplæring Id Krav 9.6 Det skal være mulig å benytte seg av leverandørens opplæringstilbud i hele avtaleperioden. Opplæring kan ytes til personer med drifts-, opplærings- og forvaltningsoppgaver hos kunden. Beskriv hvorledes opplæringsaktiviteter kan koordineres, gjennomføres og prises. 9.7 Det er ønskelig med mulighet for nettbasert opplæring som e-læring. Beskriv opplæringstyper med eventuelle påbyggingsmoduler. 9.8 Det må være en supportorganisasjon. Beskriv denne. 10-Krav til bistand etter godkjenning Det er viktig å sikre at kunden får den støtte til implementering av verktøyet som behøves i forhold til tidsplan, verktøyets hensikt og evt. behov for prosessendringer. 23

10.1-KONSULENTBISTAND OG OPPDRAG Leverandøren skal på forespørsel og etter egen avtale yte kunden bistand til: - Bistand til optimalisering av kundens drift - Bistand Videreutvikling av kundenes felles driftsløsning av verktøyet - Kundespesifikke resultat av bistand og oppdrag med unntak av eventuell testing og implementering, skal gjøres tilgjengelig for Samarbeidstiltaket FS - Andre institusjoner og andre felles tiltak i sektoren skal ha opsjon på å kunne ta i bruk verktøyet. Denne avtalen med avtalte rammer og enhetspriser vil ligge til grunn for slike leveranser. Konkret vil det måtte etableres nye versjoner av bilag 4, samt presisering av omfang, det vil si kostnader og betaling Krav til Kundens medvirkning: Avtalen punkt 10.5 Fri programvare Fri programvare som benyttes i leveransen: Navn på fri programvare Fri programvarelisens Kopi av aktuelle fri programvarelisenser skal vedlegges Leverandøren redegjørelse for sin vurdering av hvorvidt den frie programvare kan krenke tredjeparts rettigheter: Virkning av videredistribusjon: (Leverandøren må oppgi hvis videredistribusjon innebærer at også andre deler av leveransen enn det som opprinnelig var fri programvare vil bli omfattet av vilkårene i en fri programvarelisens) 24

Bilag 3 Kundens tekniske plattform Driftsmiljø I relasjon til avtalens begrepsbruk skal ulike subjekter i bilag 3 forstås avtalemessig som kunden. Uninett drifter i dag alle FS-institusjonene i samarbeidstiltaket, med unntak av UiO, UiB, UiT, NHH, UNIS og NTNU. Disse har egne databaser. Dette innebærer at de som driftes av Uninett har en felles AD-katalog, de som er utenfor har egne. De som driftes av Uninett vil i løpet av 2013 tar i bruk VPD (Virtual Privat Database). Datavarehuset (se alternativ 1 og 2 nedenfor) vil være kilde for et nytt rapport- og presentasjonsverktøy, i tillegg til rapportering direkte mot kildesystemet FS. Datavarehuset er delt opp i utvikling, test og produksjonsmiljø, og et verktøy må kunne ha tilsvarende miljøer. I datavarehuset finnes data fra FS, i tillegg til data for økonomi for UIO/UIB og forskning (CRISTIN). Brukeromfang og teknisk rammeverk Antall brukere: Antall brukere FS: Antall brukere hos institusjonene vil variere avhengig av den enkelte institusjons størrelse. Antallet brukere vil også være avhengig av hvor enkelt verktøyet oppfattes og hvor mange rapporter man vil få tilgang til via nettsider. Hver institusjon (54 stk) får tildelt lisens for en superbruker og en sluttbruker. Større institusjoner vil få tildelt lisenser for to til flere sluttbrukere etter behov. Ved full implementering antas det at det vil være i underkant av ti systemadministratorer, 50-55 superbrukere og 65-70 sluttbrukere. Hver institusjon skal i tillegg kunne kjøpe ekstra lisenser. Pris for ekstra lisenser utenom definert brukeromfang må spesifiseres av leverandør. Antall andre brukere: Det kan i tillegg komme flere brukere gjennom opsjoner. Dette gjelder: o Forskningsinformasjonssystemet CRIStin som er et verktøy for forskere og forskningsmiljøer i Norge for å registrere og profilere publikasjonsdata, prosjekter, enheter og kompetanseprofiler. Systemet brukes også til innrapportering av publikasjonspoeng. CRIStin har i dag ca. 160 institusjoner. o Økonomisystemene i UH-sektoren, herunder primært BOT-samarbeidet. BOT er et samarbeidsprosjekt mellom universitetene i Bergen, Oslo og Trondheim. Datamengde o Datavarehus: 25

Antall rader: 593.119.797 Antall tabeller: 255 Antall GB: 389 o FS Antall tabeller: 2585 pr institusjon Antall rader: 1 631 40 309 for stor institusjon (UIO), for mindre institusjon 5 757 698 rader (FSHIM?) Antall GB: ca. 812 GB for 58 institusjoner (inkl minus 30 % overhead ) Protokoller for autentisering: SAML2.0 Protokoller for autorisasjon: SAML2.0 eller LDAP Nettlesere: Firefox versjon 3.5, Internet Explorer versjon 8, Safari versjon 4 eller nyere. Standard for websider: HTML 4.01/XHTML 1.0 standard eller nyere Applikasjonsserver: 64-bits arkitektur Plattform for applikasjonsserver: Red Hat 5 eller nyere (Red Hat 6 foretrukket), alternativt Windows server 2008 R2 eller nyere Databaser: Oracle 11.2.x eller nyere versjoner. VPD- opsjon er tatt i bruk blant annet for å realisere institusjonsspesifikk tilgang til egne data, både for datavarehus og FS. Beskrivelse av kilder Datavarehus Kilde: Oracle Modellering: Stjernemodell Miljø: Utvikling, Test, Produksjon FS Kilde: Oracle Modellering: relasjonsdatabase Miljø: Utvikling, Test, Produksjon 26

Alternativer arkitekturskisser som verktøyet skal realiseres i: Det ønskes en sentral installasjon av Applikasjonstjener uavhengig av kilder, evt at det blir to sentrale installasjoner av applikasjonstjener, en mot datavarehus og en for produksjonsbaser for FS- kilder. Alternativ 1 er foretrukket løsning, men Leverandør bes om å få frem kostnad for Drift og installasjon m.m. for begge alternativene under. Alternativ 1 1. Pålogging: 3. Applikasjonstjener: Organisasjon velges av bruker Brukernavn og passord oppgis til Feide som etablerer en autentisert sesjon til verktøyet Det finnes 60 FS-institusjoner som potensielt vil benytte verktøyet. Samtlige støtter SAML2.0 enten ved at de er med i Feide eller via IDporten/MinID. Applikasjonstjener Mobil Browser Nettbrett Autentisering/autorisasjon Autentisering skal foregå ved hjelp av SAML2.0. Når støtte for SAML 2.0 er tilgjengelig for verktøyet kan protokollen også benyttes for autorisasjon. Kundene må tilgjengeliggjøre rolledata for relevant personell i avtalt attributt og på avtalt format i sin Feide-katalog (LDAP med Feide-skjema). Støtter ikke verktøyet autorisasjon via SAML2.0 må det foreligge støtte for oppkobling til eller innhenting av data fra multiple autoritative kildesystemer. 2. Feide har implementert en såkalt WAYF-tjeneste ( where-are-you-from ) som tillatter brukeren å velge hvilken vertsinstitusjon skal avgi autentiserings- og autorisasjonsdata. Feide sørger for at korrekt back-end (LDAP-katalog) velges på bakgrunn av angitt vertsinstitusjon. Verktøyet skal hente relevante data fra multiple, veldefinerte datasettsamlinger via spesifiserte grensesnitt SAML 2.0 FEIDE LDAP for institusjon LDAP for institusjon LDAP for institusjon Datavarehus Felles Studentsystem (FS) UNINETT UiO UiT NTNU UiB KILDER 27