Bilag 1: Oppdragsgivers kravspesifikasjon



Like dokumenter
Norsk historisk befolkningsregister Åpen del, histreg.no

Norsk historisk befolkningsregister

Mandat. Regionalt program for Velferdsteknologi

Vedlegg 2 KRAVSPESIFIKASJON. Anskaffelse av Medieovervåkingstjenester

Samdok samla samfunnsdokumentasjon

Moderne og brukervennlig læringsplattform (LMS) for din bedrift

Utvidet brukerveiledning

Utvikling Doffin

Introduksjon til evaluering av It-systemer. Hvordan vurdere og verdsette?

Vedlegg 1 til konkurransegrunnlaget Beskrivelse av bistanden. Kontrakt om medieovervåkning til Statens landbruksforvaltning

BRUKERVEILEDNING PROSTEMODUL FOR PRESTEN

Dette er nytt i GM EPC

automatisk informasjonssjekk av jobbsøkere på internett

Tildeling av forskningsmidler med søknadsfrist juni Veiledning for forskningsinstitusjoner og bedrifter

Kravspesifikasjon for teknisk system i forbindelse med autoritetsregistere for formidling og bibliografiske referanser tilknyttet formidling

Dokument 1 - Sammendrag

Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.

Ruter As ønsker å inngå avtaler med flere leverandører av markedsanalyse for å dekket behovet for:

AP226 Use Case Diagram - SBL

Åpne lenkede data og kulturarv-sektoren

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

K-lab Kultur, kart, kompetanse Utforsking og utprøving Mange kilder mange muligheter Koblinger. K-lab seminar, Sundvolden

Brukerveiledning for student skoleeksamen HIST Oppdatert 27. oktober 2014

1. Presentasjon av prosjekt. Forord

Bakgrunn Innlogging Brukere med tilgang Registrere infeksjoner Registrere antibiotika Registreringer...

Vårt nettsted En håndbok for lokale nettredaktører i fylkes- og lokallag

Web-rapportering og Web Økonomi i Agresso. Terje Aandalen, UNINETT

NASJONAL PUBLISERINGSPLATTFORM FOR DIGITALT MATERIALE NYE DIGITALARKIVET. SAMDOK-konferansen 2017, Anette Skogseth Clausen, Arkivverket

HVORDAN FINNE SLEKT ETTER ÅR 1900

INNBYDELSE TIL ÅPEN KONKURRANSE

Testrapport for Sir Jerky Leap

Kommentarer til kravspesifikasjon

3 Kravtabell De spesifikasjoner som fremgår av tabellen danner grunnlaget for Leverandørens løsningsforslag, jf. bilag 2.

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

PixEdit Guide MEDFAK (5. utkast)

Husk at du skal ha to vinduer åpne. Det ene er 'Python Shell' og det andre er for å skrive kode i.

Ajourføring og kontroll av skogsbilveier

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven Prosessdokumentasjon - Alternativ 1

1) Brei gjennomgang av nettportal-produktet sett fra sluttbrukerståsted

Notat. Innhold. Utvikling og innføring av Visma Flyt Skole (VFS) Til: Kopi: Fra: Dato: 7. desember Sak: Fylkeskommunene

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar Gruppemedlemmer

Kravspesifikasjon. Forord

Prosjekt «Nye kvalitetssikrings- og importrutiner for Naturbase. 5. November 2013 Terje Krogh Miljødataseksjonen

automatisk informasjonssjekk av jobbsøkere på internett

Utvikling av ATP-modellen

Forprosjekt. Profilhåndbok for Kommunikasjon 1. Hovedprosjekt ved Høgskolen i Gjøvik. Anne-Marie Finsdahl Hanne Næstad Johansen Jonas Madsen Rogne

Statistikk-og Analyseportal for Agder. Prosjektleder: Espen Moseidjord

Retningslinjer for innlegging av foto i NTNU Vitenskapsmuseets fotobase (MusIt)

Sist oppdatert av GIS-ansvarlig Hans-Victor Wexelsen

«Han (eller ho) kunne fare. Slektsforskardagen Ålesund Arnfinn Kjelland

Tilbakeføring av folkeregisteret til 1801: Kan vi? Vil vi? Tør vi?

Bilag 2 Leverandørens løsningsspesifikasjon Kultur- og naturreise app

Endrings-visualisering i GIS

Historisk befolkningsregister og DNF 1814

Nasjonal vs lokal informasjon - NFR arbeidsgruppens erfaringer og arbeid

Datasikkerhetserklæring Kelly Services AS

2 Grafisk grensesnitt 1

Leverandørregisteret. Søk og vedlikehold. VISMA RETAIL AS Wirgenes vei 1, 3157 Barkåker, Telefon:

K-Nett. Krisehåndteringssystem for Norges vassdrags- og energidirektorat i en beredskaps- og krisesituasjon. av Erik Mathiessen

FISKERIDIREKTORATETS STATISTIKKBANK

BRUKERHÅNDBOK FOR UNIVERSITETET I OSLO. (Versjon )

Eneboerspillet del 2. Håvard Johnsbråten, januar 2014

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

Testverktøy Status og videre tanker

NÅ KOMMER NYE YAHOO! SPONSORED SEARCH

geonorge - en geografisk tjenestebasert infrastruktur uten sidestykke.

Versjonen er tatt i bruk fra juli 2010 og gjelder fra og med rapporteringen som avsluttes 15. juli De mest vesentlige endringene er:

Løsningsforslag til Case. (Analysen)

UML 1. Use case drevet analyse og design Kirsten Ribu

Infografikk over innvandrerstatistikk Emil Gabrielli

Plan som obligatorisk datasett i Norge digitalt. Kåre Kyrkjeeide

Forespørsel: FRAM Nettauksjonstjenester. Del 2 VEDLEGG C: KRAVSPESIFIKASJON KRAVSPESIFIKASJON. FOR ANSKAFFELSE AV Nettauksjonstjenester

Brukerveiledning for å legge inn Støtteordning, Rammer, Forenklet tilsagn, Endringer på tilsagn, Årsrapportering

Bridging the gap: taking BIM to the construction site Case: BIM-kiosker på Urbygningen ved NMBU

CustomPublish.com. Filbehandling. Introduksjon til filbehandling i CustomPublish

1. Generelt. FM-OA, Kompletterende undervisning Innledning Stikkord Prosessen. Spec 2, datert

Memoz brukerveiledning

Moderne og brukervennlig læringsplattform (LMS) for din bedrift

Huldt & Lillevik Lønn Lønn 5.0. Versjon

Historisk befolkningsregister

WinMed3. Release Notes Allmenn Våren Release Notes Allmenn Våren 2013 Versjon Side 1

Undervisningsopplegg i matematikk. Med fokus på bruk av IKT

Per styremøte

«Glød og go fot» Utviklingsstrategi. Orkdal kommune. Nyskapende. Effek v. Raus Våre strategier er:

Systemutvikling (Software Engineering) TDT 4110 IT Grunnkurs Professor Guttorm Sindre

VITEC. Veiledning nytt år. EmProf årsavslutning LAST EDITED:

Finansportalen Historiske bankdata

AV-teknisk utrustning for Vegtrafikksentalen Region nord (VTS nord) Svar på innkomne spørsmål til konkurransegrunnlaget pr

Tema: Nytt skoleår Fronter 92

Erfaringer fra bytte av sak-arkivsystem i Rana kommune fra Esa til ephorte

Høring - rapport fra Statens kartverk om det offentlige kartgrunnlaget

VEDLEGG 1. Utvikling av nytt nettsted og videreutvikling av profil og visuell identitet for Norsk filminstitutt. Kravspesifikasjon

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

Veiledning for innlevering av Årsrapport

Maritech Lønn versjon (Endringer etter versjon )

Naturbase et hjem for utvalgte naturtyper og prioriterte arter. Samling Rica Nidelven Pål Theodorsen, DN

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING

hypernet Kommunikasjon Brukermanual

BRUKERVEILEDNING PROSTEMODUL FOR PROST OG PROSTESEKRETÆR OPPSETT AV PROSTIET

Hvordan komme i gang på

Transkript:

Bilag 1: Oppdragsgivers kravspesifikasjon Avtalens punkt 1.1: Avtalens omfang Bakgrunn og formål med anskaffelsen: Historisk befolkningsregister (HBR) er et prosjekt med ambisjoner om å lenke all tilgjengelig, transkribert og digitalt skapt person- og stedsinformasjon fra ca. 1800 og fram til i dag sammen i en database. Personinformasjonen fra de ulike kildene skal lenkes sammen til livsløp på individnivå. Tilsvarende også for gårds- og eiendomsinformasjonen. I tillegg skal individene kobles sammen ved å opprette slektskapsrelasjoner mellom dem, også disse basert på informasjonen i kildene. Den eldste delen av registret, i utgangspunktet for perioden 1800-1919, vil bli bygd opp ved hjelp av en wikiløsning kalt HBR-wiki. Wikien vil være åpen for alle på nettet, både for bruk av registret (søk, oppslag osv) og for frivillige bidrag til lenkingsarbeidet. HBR fikk støtte fra Norges forskningsråd til et forprosjekt i 2010-2011, men fikk høsten 2011 avslag på sin søknad om midler til et hovedprosjekt for perioden 2012-2016. Mens det arbeides med flere nye søknader om finansiering av HBR, har Riksarkivaren opprettet et delprosjekt kalt Det norske folk i 1814 (DNF 1814). Dette går ut på å bygge opp et nasjonalt befolkningsregister for perioden 1801-1815, med fokus på året 1814 i anledning grunnlovsjubileet i 2014. Kildegrunnlaget vil være den nominative folketellingen 1. februar 1801, lister over døpte, viede og begravde i kirkebøkene i perioden 1801-1815, og nominative lister fra folketellingen 30. april 1815, der slike er bevart. Det er besluttet å benytte HBR-wiki til oppbygging av dette delregistret, og Riksarkivaren har derfor påtatt seg å finansiere de første fasene i utviklingen av wikiløsningen. Utvikleren kan forvente at utviklingen av HBR-wiki vil skje i løpende samarbeid med Riksarkivet, RHD og muligens andre deltagere i HBR-konsortiet. Disse vil stå for detaljspesifisering av rutiner og funksjoner, uttesting, faglige premisser for løsningen osv. Og ikke minst for innbyrdes prioritering av utviklingsoppgavene. Status for utvikling av HBR-wiki i fase 1, se bilag 3. Kundens krav til leveransen: Overordnet kravtabell for fase 2 (1. halvår 2012): 1 Forbedre og effektivisere funksjonene for interaktiv lenking og innlesing av eksternt lenket materiale Når HBR-wiki tas i bruk, vil det trolig komme krav om og forslag til forbedringer av rutinene i systemet, særlig de interaktive lenkingsrutinene. Flere av kravene og forslagene bør følges opp og implementeres så raskt som mulig. Aktuelle forbedringspunkter kan f.eks. være logging av lenking og de-lenking, prioriteringene ved og gjennomføringen av akkumulering av kjerneinformasjon ved lenking, fremfinning og visning av kandidater for lenking, markering av kandidater for lenking og

personforekomster for «avskalling», muligheter for manuell redigering av kjerneopplysninger om personen osv. Det kan også komme ønsker om utvikling av helt nye støttefunksjoner i arbeidet. Det kan også oppstå forbedringsbehov knyttet til selve brukerhåndteringen, f.eks. logging av aktivitet, begrensing av aktivitet (f.eks. funksjonelt eller geografisk), utestengelse osv. Superbrukere vil trolig trenge flere tilleggsfunksjoner. MediaWiki vil ha basisrutiner for noe av dette. Utvikleren må ha ressurser i beredskap til slike oppgaver. 2 Utvikle søkerutine med fokus på å samle lenkede personer og ulenkede personforekomster som kandidater for interaktiv lenking. Både lenkede personer (personsider) og ulenkede forekomster av personer (som også er personsider) vil i HBR-wiki bli plassert i en rekke overlappende kategorier basert på personenes egenskaper. Men dette er neppe nok for å samle og synliggjøre alle kandidater for videre lenking. Det vil være behov for en søkerutine der lenkerne kan søke frem lenkingskandidater (personsider) på grunnlag av ulike kriterier i kombinasjon, f.eks. navn, fødselsår, fødested, hendelsesperiode, geografisk område, kilde o.a. Søkerutinen er også viktig for ordinære brukere av wikien, til fremsøking av egne slektninger eller oppslag av enkeltindivider. 3 Forbedre brukergrensesnittet i HBR-wiki med fokus på bedre plassutnyttelse på skjermen. Brukergrensesnittet i dagens prototyp av HBR-wiki er ganske rudimentært. Funksjonalitet har vært prioritert så langt. Mye kan forbedres ikke minst ved å utnytte plassen i skjermbildene bedre både i lengden og bredden (uten horisontal scrolling). Særlig gjelder dette ryddigheten og lesbar-heten til tabelloppsettene (livsløpstabellen m.m.). Her kan en del gjøres ved å justere fontstørrelsen, innføre rutenett, bruke skygge/farger osv. Kategorivisningene har også et forbedringspotensial, og det samme har hovedoppsettet av sidene med menyer, lenker, grafikk osv. Sidene skal være lettfattelige, oversiktlige og effektive i bruk. Det bør også utarbeides flere veiledninger og hjelpetekster til brukerne. 4 Utvikle rutine («robot») for bl.a. logisk testing av lenkede personers livsløp. Ved interaktiv lenking er det ikke alltid lett for lenkeren å overskue følgene av de lenkene han/hun oppretter. Det kan være logiske brister i det resulterende livsløpet (f.eks. umulig rekkefølge eller avstand i tid mellom ulike begivenheter i livet), og det kan oppstå inkonsistens mellom familierelasjoner som allerede er knyttet til

lenkingskandidatene (f.eks. at to sannsynlige forekomster i samme livsløp er koblet til forskjellige mødre). Dette kan skyldes feil i dataene eller feil i tidligere opprettede lenker. Det skal i denne fasen utvikles en kontrollrutine som skal kunne avdekke et visst minimum av slike logiske brister, og melde fra til lenkeren om disse. Lenkeren må selv få styre tiltakene for å rette opp feilen(e). Kontrollrutinen(e) vil bli videreutviklet i senere faser. 5 Utvikle funksjon for interaktiv «avskalling» av feillenkede begivenheter fra en lenket persons livsløp. Kontrollrutinen i krav 4, lenkeren selv eller en annen bruker kan oppdage at en bestemt personforekomst ikke passer inn i det livsløpet den er lenket til. Det må da være mulig på en enkel måte å «frigjøre» denne forekomsten fra dette livsløpet (denne lenkede personen), og reetablere forekomsten som en separat, ulenket personside. 6 Utvikle funksjon for interaktiv oppsplitting (delenking) av lenket person. Det vil trolig også forekomme mer omfattende feil/inkonsistens i livsløpene, og da vil det være bedre å ha en rutine som oppløser den lenkede personen (livsløpet) fullstendig, og reetablerer alle forekomstene som separate personsider. I denne situasjonen vil det være en utfordring hvordan manuelt tilføyd/redigert informasjon (f.eks. kjerneopplysninger, biografi og opplastede bilder etc.) skal håndteres/fordeles. 7 1.1. Lage innlesingsrutiner for flere listetyper fra kirkebøkene, emigrantmateriale og matrikkel. HBR-wiki kan i dag lese inn data fra folketellinger i HistformML-format og data fra dåps-, vielses- og begravelseslister i kirkebøker i KyrreML-format. Begge disse formatene inneholder Digitalarkivets permanente kildeider og personkilde-ider. Utvidelsesbehovet på kort sikt er å kunne lese inn data fra dødfødsels-, innflytter- og utflytterlistene og eventuelt konfirmantlistene i kirkebøkene. Det vil også være behov for innlesing av matrikkelen 1838 og emigrantmateriale. 8 Utvikle spesielle datavisninger. Det vil være behov for å utvikle skreddersydde visninger av befolkningen i 1814, f.eks. oversikter over dem som dette året var bosatt eller ble født i hvert enkelt prestegjeld i landet, pluss statistikk knyttet til disse. Det samme gjelder også oversikter over bosetningen på de enkelte gårder. Kategoriene i HBR-wiki vil kunne

utnyttes til noe av dette, men det vil ventelig komme utvidede ønsker. F.eks. vil lenker fra de 112 eidsvollsmennenes sider i HBR-wiki til deres respektive sider på www.eidsvollsmenn.no (et annet av Arkivverkets jubileumsprosjekter) være sterkt ønsket. Detaljer for dette og andre funksjoner og visninger vil bli spesifisert senere. 9 Justere kategoriinndelingen i HBR-wiki hvis behov I dagens prototyp av HBR-wiki er det lagt opp til en ambisiøs, detaljert inndeling av person-, familie-, stedsog kildesidene i overlappende kategorier. Dette ser bra ut i teorien, men det er vanskelig å bedømme hvordan dette vil fungere med de store data- og metadatamengdene det er snakk om i HBR-wiki. Det vil trolig måtte bli en balansegang mellom antall kategorier (titusenvis) og antall sider i hver kategori (titusenvis). En faktor er hva basisprogramvaren MediaWiki kan håndtere, en annen faktor er hva brukerne greier å forholde seg til. Det vil høyst sannsynlig bli behov for visse endringer og justeringer i bruken av kategorier. Utvikleren må ha ressurser i beredskap til oppgaver knyttet til dette. 10 Utvikle rutine for oppslag av (lenket) personside i HBR-wiki på grunnlag av kjent personkilde-id. Det har helt fra den tidlige planleggingen av HBR-wiki vært en intensjon at samspillet mellom wikien og Digitalarkivet (og senere RHDs nettsted o.a.) skal baseres på weblenker begge veier. Lenkene fra HBR-wiki til Digitalarkivet er enkle å realisere, siden de er basert på de kilde- og personkilde-idene som ligger i dataene ved import i wikien. Men vi ønsker også en weblenke fra en hvilken som helst (visning av) en personforekomst i Digitalarkivet til denne personens side (lenket person) i HBR-wiki. Dette må fungere selv om ikke den aktuelle personkilde-iden er den primære personiden for en lenket person i wikien. HBR-wiki trenger følgelig en maskinell oppslagsrutine for fremfinning av personsiden til en hvilken som helst personforekomst basert på forekomstens personkilde-id. 11 Fortløpende rette feil i og vedlikeholde programvare utviklet i fase 1 og 2, inkludert å effektivisere «flaskehalser». Det må i fase 2 forventes å være stadige behov for å rette feil i og tilpasse/vedlikeholde programvaren utviklet både i fase 1 og 2. Dette kommer i tillegg til videreutviklingen i punkt 1 ovenfor. Utvikleren må sette av ressurser til slikt vedlikehold.

12 Utarbeide dokumentasjon av programvare utviklet i fase 2, både på funksjonelt og teknisk nivå. Programvaren må dokumenteres både på detaljnivå ved hjelp av kommentarlinjer i programkoden, og på et mer overordnet nivå ved hjelp av egne dokumenter med figurer og tilhørende, beskrivende tekst (systemdokumentasjon). I de sistnevnte dokumentene må arkitekturen i løsningen og samspillet mellom moduler beskrives, samt hvilke forutsetninger implementeringen av løsningen bygger på. Nedenfor følger en liste over utviklingsoppgaver for fase 3 og 4 (fra høsten 2012) og utover. Disse oppgavene gjelder både HBR-wiki og aktiviteter rundt wikien, blant annet for transkribering av kilder. Listen er mest å betrakte som en idéskisse for oppgaver til kommende faser, og det kan forekomme justeringer av oppgaver mellom fasene. Overordnet kravtabell for fase 3 (høst 2012 vår 2013) 13 Utvikle metode og funksjoner for å erstatte grunnlagsdata. Det vil bli behov for å erstatte kirkebokslister, folketellinger osv. med nye, korrigerte versjoner. 14 Utvikle et system for feilrapportering fra brukerne, med oppfølging og tilbakerapportering. Transkriberingsfeil i dataene må rettes av dataeierne etterfulgt av ny-import av grunnlagsdata med visse mellomrom (jf. krav 13), mens lenkings- og koblingsfeil (feil i slektskapsrelasjoner) må rettes i wikien. 15 Utvikle funksjoner for bedre kontroll og kvalitetssikring av det interaktive arbeidet i wikien. Mulighet for å varsling av mulige feil og diverse støttefunksjoner. Inkluderer egne sider i wikien for brukerstøtte. 16 Utvikle gode utskriftsfunksjoner for de ulike sidetypene i wikien.

17 Utvikle funksjoner for å lenke inn i livsløpstabellen forekomster der personen opptrer i eksterne kilder og andre nettressurser. Dette gjelder datamateriale som ikke er innlest i wikien. Det kan være lenker til aviser (dødsannonser, nekrologer osv.) og kilder på andre nettsteder (f.eks. amerikanske immigrasjonskilder eller DIS-Norges Gravminner i Norge). 18 Utvikle en «robot» som går gjennom hele wikien og sjekker at alle weblenker virker. 19 Utvikle funksjon for innlesing av filer med eksplisitte slektskapsrelasjoner mellom individer i wikien. Skal brukes til etablering av relasjoner og familiesider i wikien. 20 Utvikle funksjon for innlesing av historisk matrikkel (GeoUnit, del av HAG-prosjektet). Bygge stedssidene i HBR-wiki over denne istedenfor folketellingene. 21 Utvikle funksjon for å lese inn matrikler. Matriklene 1886, 1904, 1950. Knytte disse til den ovennevnte historiske matrikkelen. 22 Utarbeide rutiner for systematisk etablering av weblenker på personnivå. Til RHDs nettsted, NAPP, lokalhistoriewiki, bygebøker på nett, litteratur, Wikipedia osv. 23 Legge tilrette for etableringen av weblenker og andre relasjoner i wikien til andre prosjekter og institusjoner. Dette kan være til lokale lag i DIS-Norge, Norsk slektshistorisk forening, historielag, museer, arkiver, etniske grupper, nettsider for turister og ikke minst til forskningsrelaterte institusjoner og nettressurser, f.eks. medisinske registre og institusjoner som Norsk samfunnsvitenskapelig datatjeneste.

Overordnet kravtabell for fase 4 (høst 2013 vår 2014) 24 Utvikle funksjoner for grafiske visninger av data i wikien. Dette kan gjelde anetavler, slektstrær, tidslinjer for familier, kart som viser flytting for person eller familie, migrasjonsmønstre for befolkningen i ulike perioder osv (eksempler i Demografiska databasen, WeRelate, Geni og andre nettbaserte slektsprogrammer). 25 Utvikle statistikkfunksjoner. For beregning og visning av dekningsgrader, lenkingsstatus, demografiske variabler o.a. (med tabeller og grafikk). Eksempler på interaktiv, web-basert statistikkfunksjon kan finnes hos North Atlantic Population Project (www.nappdata.org) og IPUMS (www.ipums.org/). 26 Implementere algoritme for å finne evt. slektskap mellom to individer i wikien. Slike funksjoner finnes i andre slektsprogrammer. 27 Utvikle funksjon for eksport av data fra wikien til import i HBRs forskningsdatabase. 28 Utvikle funksjon for eksport av slektsdata fra wikien i Gedcom-format. For import i slektsprogrammer o.a. 29 Utvikle funksjoner for eksport av bestemte datasammensetninger i XML-format. 30 Utvikle funksjoner for å lenke til personforekomster som er innlest i wikien, men i «kildetabeller» i stedet for separate personsider. 31 Utvikle kartfunksjoner over wikien. Basert på resultater fra prosjektet Nasjonale karttjenester for historiske, administrative grenser (HAGprosjektet).

Avtalen punkt 2.3.3: Utviklingsverktøy utviklingsmetode Kundens krav til utviklingsmiljøet eller metode: 1 Programvaren for HBR-wiki skal være basert på MediaWiki, som er åpen kildekode under GNU General Public License. Det innebærer at den programvaren som tilpasses og nyutvikles for HBR-wiki, også må legges ut som åpen kildekode. 2 Tilpasninger og videreutvikling må gjøres slik at basisprogramvaren MediaWiki når som helst kan byttes ut med en ny versjon. Videreutviklingen må foregå på en utviklingsmaskin, og oppdatert/ny funksjonalitet overføres til produksjonsserveren når det er ønskelig. Tilleggspakker til MediaWiki må kunne inkluderes og tas i bruk. 3 Løsningen bør skaleres for noen hundre samtidige brukere via Internett. Tilgjengelighet, oppetid og responstid vil være svært viktig. 4 Systemet må kunne takle at to brukere samtidig forsøker å lenke eller oppdatere kjerneinformasjon om samme individ i wikien. Avtalen punkt 2.3.5: Utarbeidelse av dokumentasjon til dokumentasjon: 1 Utarbeide dokumentasjon av programvare både på funksjonelt og teknisk nivå. Programvaren må dokumenteres både på detaljnivå ved hjelp av kommentarlinjer i programkoden, og på et mer overordnet nivå ved hjelp av egne dokumenter med figurer og tilhørende, beskrivende tekst (systemdokumentasjon). I de sistnevnte dokumentene må arkitekturen i løsningen og samspillet mellom moduler beskrives, samt hvilke forutsetninger implementeringen av løsningen bygger på.