Krav til biblioteksystemer

      Foreleser: Runar Eggen, epost: [email protected]

Trenger vi spesifisere krav?

Litt om kravspesifikasjoner Bibliotekstandarder IT-standarder Funksjonalitet i biblioteksystemer

Trenger bibl. stille krav?

    Er ikke de systemene bibliotek trenger ferdige?

Hvorfor skal vi lære om kravspesifikasjoner?

Enkelte av dagens systemer over 20 år gamle Utvikling går fort

Hvorfor stille krav?

     Viktig å vite hva man betaler for Viktig å vite om man kan få mer for pengene et annet sted Plikt til å utnytte ressursene til beste for bibliotekeier/brukere Bibliotekarens viktigste verktøy Må ikke bare kunne bruke systemet, men også velge det system som er best

Konservativisme 1

   Har man arbeidet 20 år i et system, er det kanskje det eneste man kan.

Da forsvarer man status quo, selv om det er faglig galt.

Leverandører kan også ha interesse av å forsvare status quo.

Konservatisme 2

   PC-brukere, Mac-brukere og Unix-tilhengere er ofte nærmest fundamentalister. Det samme gjelder biblioteksystembrukere.

De fleste biblioteksystem kjører i dag på Windows eller Linux/Unix, men dette er ingen naturlov. Enkle brukergrensesnitt senker endringsterskelen, fordi bruker må investere mindre tid i systemet.

Et lite regnestykke

   Et bibliotek skal katalogisere 100.000 bøker. I ett system bruker man ett minutt lenger på hver katalogisering. En billig arbeidstime koster 200 kr.

I løpet av katalogiseringsprosessen bruker man 1667 timer eller 333.333 kr ekstra på et ineffektivt system.

For 300.000 kr får man kjøpt mye biblioteksystem.

Spesifikasjonen vanskeligst

   Ikke noe annet kan i samme grad forkrøple sluttresultatet som kravspesifikasjonen.

Jo seinere en feil i programvaren oppdages, jo dyrere er de å rette opp.

Mange feil er latente og oppdages først i en annen fase enn de oppstod i.

  Det gjøres mange feil i krav.

Typisk er uriktige fakta, utelatelser, inkonsistenser og tvetydigheter.

 Feil i krav kan oppdages.

Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

Kravspesifikasjoner som gikk galt

  TRESS-90. Trygdeetatens nye system ble skrinlagt etter at flere hundre mill. kr. var brukt.

Ariane 501-raketten, ESAs prestisjeprosjekt. Raketten eksploderte 30 sek. etter oppskytning pga. spesifikasjonsfeil i programvaren til styresystemet.

Viktige suksessfaktorer

   Brukermedvirkning Støtte fra toppledelsen Klart definerte krav  Andre faktorer: skikkelig planlegging, realistiske forventninger, kortere milepæler, kompetent personale, eierskap, klar visjon og mål, hardt arbeidende og fokusert stab.

Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

Spesifikasjonens faser

    Finne behov. Problemanalyse Fastsette krav Spesifikasjon av krav Kontroll av endringer i krav Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

Vanligste feil i kravspek

   Manglende info – Funksjon, egenskap – Grensesnittdefinisjoner – Ytelseskrav (svartid, databasebelastning) – Kvalitetskrav (menneskelige faktorer, pålitelighet, sikkerhet) Gal info – Konstruksjon istedenfor krav – Ikke hva kunden ønsker – Tvetydige krav – Inkonsekvente krav – Ikke testbare krav Unødvendig info – Kjekt å ha Kilde:http://www.aitel.hist.no/fag/_pum/omkrav/omkrav.doc

Kravspek for utvikling/kjøp

   Biblioteksystemer er til en viss grad hyllevare, og de fleste bibliotekarer vil derfor i liten grad ta del i systemutvikling.

Men for mange bibliotek vil valg og innføring av et nytt system være et stort prosjekt som krever en spesifikasjon.

Det kan ofte bli snakk om tilpasninger av hyllevare.

Krav skal leve lenge

  Kravspesifikasjonen skal leve lenge, ofte lenger enn de første programmene den spesifiserte.

Det er derfor viktig at den er modifiserbar. Da må den være konsistent, og ikke redundant. Dvs. at et man bruker ord konsekvent og at et tema/objekt behandles ett sted.

Databasen viktig(st)

    Databasen er minst like viktig som programmene. Dataene skal leve lenger.

Databasestruktur må kunne endres.

Data må kunne masse-endres og hentes ut uten programmering.

Viktig å følge standarder, som f.eks. SQL.

– Ikke alle biblioteksystem gjør dette.

Brukervennlighet og fleksibilitet

   Det er av og til en konflikt mellom brukervennlighet og fleksibilitet.

En programleverandør som får motstridende krav fra forskjellige kunder, må velge mellom å vedlikeholde forskjellige kodeversjoner eller å legge inn parameterstyring av programmene.

Stor grad av parameterstyring kan gjøre systemet komplisert å sette opp og bruke. Løsning: Gode installasjonsprogrammer og dokumentasjon. Evt. sentral drift.

Brukervennlighet 2

 Brukergrensesnitt i et biblioteksystem bør likne andre programmer slik at kunnskap får overføringsverdi.

Bibliotekstandarder 1

 MARC-formatet - hvilket MARC-format?

– MARC-formatet langt fra perfekt – Unødvendig komplisert (00-feltene, indikatorer, delfelter) – Lite egnet for programmering – Lite konsekvent (bl.a. bruk av indikatorer) – Selvmotsigende (for eksempel aldersgrupper i 008 feltet) – Snevert (kun brukt av bibliotek) – Foreldet – MEN bedre med en standard enn ingen!

Bibliotekstandarder 2

      MARC-formatet er så utbredt at det blir krevende å skifte det ut.

Tendens til å gå tilbake til ett MARC-format (UKMARC er lagt ned, svenskene går over til MARC21.) XML kan bli viktig framover. Generelt format med generelle verktøy XML-innpakket MARC Hva betyr det at man er XML-kompatibel?

Dublin Core kan redusere behovet for MARC katalogisering.

Bibliotekstandarder 3

 Dublin Core The Elements (ikke bare bibliotek) – Title – Creator – Subject – Description – Publisher – Contributor – Date – Type – Format – Identifier – Resource Identifier – Source – Language – Relation – Coverage – Rights

Bibliotekstandarder 4

 AACR 2 – Ble til i en annen tid (hva trenger du ordningsord til i dag for eksempel?) – Hva er ordningsord? (tenk biografier) – Svært detaljert – Systemene tar hånd om mye av reglene (. trenger du ikke tenke på lenger) – ISBD-visning en fordel, men ikke absolutt nødvendig. Men KOMPAKT og lett å lese!

– Bedre med en standard enn ingen!

Bibliotekstandarder 5

     CCL – Common Command Language Mange sier de følger det.

Men ofte har de bare noe som likner.

Hvem vet hva det er?

Spiller det noen rolle?

Bibliotekstandarder 6

  Z39.50 er en protokoll for samtidig søking og oppdatering i flere databaser. Fra 1990-årene. Programvare tilgjengelig lenge, men begrenset utbredelse.

NILL – Norsk fjernlånstandard (Norwegian InterLibrary Lending). Ganske ny, de første applikasjonene ute nå.

IT-standarder – operativsystem 1

    Tre hovedtyper: Windows, MacIntosh og Unix (Linux er en Unix-variant) Windows og Unix mest aktuelle for biblioteksystemer Alle operativsystemene gir mulighet for grafisk grensesnitt Eldre biblioteksystemer har tegnbasert grensesnitt (BIBSYS, eldre Bibliofil-versjoner, Mikromarc 1)

IT-standarder - operativsystem 2

     Windows - hvilken Windows? 32 og 16 bits Windows 32 bits programmer går ikke på Windows 3.x

32 bits Windows er fra og med Win95 Hvis en leverandør sier at systemet går på 16 bits Windows, skal du ikke kjøpe det. Det betyr at det ikke utnytter mer moderne Windows versjoner.

IT-standarder - operativsystem 3

     Operativsystemuavhengig?

Web-baserte biblioteksystemer sies å være operativsystemuavhengig. Stemmer det?

På serversiden: Serveren må kjøre ett eller annet operativsystem. På klientsiden: Ja, men ikke alle systemer støtter alle HTML-versjoner, og er heller ikke like gode i alle nettlesere. Et system bør la seg kjøre i de vanligste nettleserne. I Norge i dag (oktober 2004) er dette Opera, Mozilla og Internet Explorer.

IT-standarder – grensesnitt 1

  Grafisk grensesnitt et absolutt krav i dag – Det er bare en viktig systemleverandør i Norge som ikke oppfyller dette.

Unicode – gjør det mulig å representere alle alfabet i ett tegnsett. 16 bits tegn istedenfor 8, hvilket gir 65536 forskjellige tegn istedenfor 255. De færreste biblioteksystem tilbyr unicode i dag.

IT-standarder – grensesnitt 2

  Web-grensesnitt begynner å bli vanlig, ikke bare for søk, men også for utlån og katalogisering Web-grensesnitt har mange fordeler og minst en ulempe – Fordeler: operativsystemuavhengig på klientsiden, små krav til linje, stedsuavhengig – Ulemper: vanskeligere, men ikke umulig, å få inn funksjonalitet

Klient-tjener (client-server)

     Teknologien populær i Windows-miljø Tynne eller tykke klienter (tynne krever mindre av linjer og maskiner) Windows krever ”mellomklient” hvis man må via internett for å nå serveren.

Citrix ICA-klient brukes bl.a. av MM2.

Flerlagsarkitektur (multi-tier) gjør klientprogrammene og serverprogrammene mer uavhengige av hverandre.

IT-standarder – dokumenter

    Dokumenter bør være i standard formater.

Dokumenter bør ikke være i proprietære formater som Microsoft Word osv.

Dokumenter skal kunne leses om flere hundre år.

Derfor er XML viktig for bibliotek.

Funksjonalitet i biblioteksystemet

 Her skal vi se på: – Hva ” alle ” systemer har/bør ha – Hva noen systemer har – Nye tjenester – Bibliotekmarkedet – Biblioteksystem-markedet

Hva ”alle” systemer har/bør ha

        Innkjøpssystem Katalogsystem m/autoritetsregister Utlånssystem Publikumssøk m/bestilling, melding på web Tidsskriftsystem Statistikk og rapportfunksjon enkel å bruke!

Sanntids oppdatering, én database Filialhåndtering, konsortiehåndtering

Skille klinten fra hveten

  Siden "alle" systemer har de fleste basisfunksjonene, blir det viktig å vite hvor forskjellene ligger.

Ikke alle forskjellene like nødvendige, men de kan fortelle om utviklingstakt.

Hva noen systemer har 1

         Publikumstjenester: Mappa mi/Lånerprofil Selvbetjening og utlånsautomat Epost- og SMS-varsling (forfalte lån, ank. reserveringer) Søk fra mobiltelefon Katalogkrydder/Innsyn Visning av fulltekstdokumenter Z39.50-basert samsøk Z39.50 server og Z39.50 klient

Hva noen systemer har 2

         Utlån System nede-funksjon Fjernlånssystem Direct mail til lånergrupper Forhåndsreservering til en best tid (booking) Boken kommer Bilde av lånerne Forskjellige lydsignaler i utlånsskranke Import av lånerdata fra skoleadm. systemer

Hva noen systemer har 3

    Katalog/Innkjøp: Enkel kopiering av katalogposter fra andre Filtre ved import av data for å luke ut uønsket informasjon Integrert innkjøp av bøker (Ved bestilling i nettbokhandel overføres katalogdata og innkjøpsdata til ditt biblioteksystem)

Hva noen systemer har 4

     Generelt: Grafisk grensesnitt Brukertilpasning (skjermbilder, søkbarhet, rettigheter, rutiner etc.) Replikering (kopiering av db med toveis oppdatering) Sentral drifting

Hva noen systemer har 5

   Generelt: Databasen bør være SQL-kompatibel, eventuelt kompatibel med etterfølgende standarder Alle klientfunksjoner bør kunne kjøres i en nettleser (se f.eks. reindex.net)

Bokomslag, omtale, innh.fort.

  ISBN brukes til å koble den lokale bibliotekkatalogen til en sentral base der omslagsbilde, forlagets bokomtale, baksidetekst og, i noen tilfeller, innholdsfortegnelse ligger.

Flere norske biblioteksystemer har tatt i bruk slike løsninger.

Bokomslag, bokomtale, innh.fort.

Også BIBSYS har dette

Og Bibliofil har det

Mulige nye tjenester 1

    Samtidig oppdatering av flere systemer (Z39.50 gjør det mulig å katalogisere i flere baser samtidig) Forbedret samtidig søk i flere baser (Se UB Karlsruhe, BIMIN, NORZIG) http://www.ubka.uni karlsruhe.de/hylib/en/kvk.html

http://min.bibl.no/

Mulige nye tjenester 2

  Automatisert fjernlån (NILL) Integrering av digitale ressurser – innebærer at systemet kan se hvilke tidsskrifter institusjonen abonnerer på, og brukerne kan dermed lese disse på sin PC

Mulige nye tjenester 3

     Open Archive Initiative – Automatisk høsting av data til samkataloger – Automatisk høsting av data til tverrfaglige databaser (f.eks. Oljedirektoratet) Open URL (standard) Norsk digitalt bibliotek (ABM) Søk i heterogene ressurser, f.eks. bibliotek/bokhandel/web som hos UB Karlsruhe, SFX/Metalib, Z portal, Endeavor) Paradigmeprosjektet (arkivering av Internett). Kun for forskere!

Mulige nye tjenester 4

    Felles lånerkort for alle norske bibliotek (prosjekt igangsatt) Håndtering av alle tegnsett (arabisk, hindi etc. krever Unicode, få systemer har det i dag) Sentralt vedlikeholdte databaser over databaser (SFX/Metalib) Emneportaler (Bibsys m.fl.)

Mulige nye tjenester 5

  Vekting av treff. Dette gjøres i søkemotorer på web, hvorfor ikke i biblioteksystemer?

Komponentbaserte systemer – Biblioteksystemet kan settes sammen av standardkomponenter fra forskjellige leverandører – Korter utviklingstid og øker omstillingsevne

Initiativ savnet!

     Z-portaler ikke på langt nær så utbredt som man skulle tro Regionale portaler f.eks. folkebibl.

Faglige portaler Markedet har ikke fungert her Naturlig oppgave for Norsk Digitalt Bibliotek og ABM!

Bibliotekenes framtid

      Lex armlengde – man er interessert i de bøker man har innen armlengdes avstand.

Lex tastetrykk informasjon man har tilgjengelig ved hjelp av et par tastetrykk.

– man er interessert i den Informasjon her og nå – ikke om ei uke jfr SFX/Metalib Ingen bruker fornøyd med en referanse!

Lånere skal ikke behøve gå til biblioteket!

Sluttbrukerstyrt fjernlån

Hvordan det kan gjøres

  The Cochrane Library er frikjøpt av SHDIR for alle norske brukere – en av verdens aller beste medisinske databaser. Sjekker om du kommer fra en norsk IP adresse.

http://www.cochrane.no/files/Library.cfm

Systemgenerasjoner

    1. generasjon : Tegnbaserte stor/minimaskinsystemer. Proprietær db.

Katalog og utlån ofte de første modulene.

2. generasjon : Tegnbaserte PC-systemer.

3. generasjon : Grafisk grensesnitt. "Komplette systemer". Web-basert publikumssøk. Lenking til fulltekstdokumenter. SQL database.

4. generasjon : Komponentbasert. Gjennomført web grensesnitt i hele systemet. Fulltekst integrert, som f.eks. søking i fulltekstdokumenter, samtidig søk i heterogene ressurser, kobling til elektroniske tidsskrifter, systemet vet om du har abbonnement. Z-portaler. Mobiltelefoner/mobile terminaler.

Bibliotekmarkedet

   Hovedgrupper Allmenne (folkebibliotek, videregående skoler, grunnskoler) Fagbibliotek – Høyskoler (små og mellomstore) – Universitet (store) – Spesialbibliotek (sykehus, musikkbibliotek, departementer, oftest små) – Firmaers informasjonssentre (ikke opphengt i marcformat eller tradisjonelle bibliotekdyder)

Biblioteksystem-markedet

 Forskjellige systemer dominerer de forskjellige markedsnisjene. Ofte historiske årsaker til hvilke systemer som dominerer hvilke nisjer, ikke nødvendigvis systemenes egenskaper avgjørende.

    Folkebibliotek: Bibliofil, Mikromarc og Aleph Skolebibliotek: Mikromarc, Bibliofil og Tidemann Universitet og høgskoler: Bibsys, Aleph og Mikromarc Spesialbibliotek: Mikromarc, Tidemann, Bibsys og Bibliofil

Faktorer å vurdere ved kjøp 1

       Funksjonalitet, brukervennlighet Videreutvikling Lett å skifte ut (dataene viktigere enn system). Må med i kontrakt!

Operativsystem, maskinplattform, minnekrav Norsk leverandør og brukerstøtte Pris (anskaffelse, årlig avgift, hjelp) Samarbeid med andre bibliotek

Faktorer å vurdere ved kjøp 2

    Er systemet moderne i dag?

Hvis ikke, er det sannsynligvis at det vil være det om et år? Om fem år?

Systemene i norske bibliotek er 1.- 3. generasjon, men 4. generasjon er tilgjengelig.

Vi kan derfor komme til å se en omfattende utskifting i de neste årene.

Sentral drifting

  Fordeler: – IT-avdelinger glade for å slippe ansvar for biblioteket (marginalt) – Biblioteket glade for å slippe ansvar for IT (kompetanse) – Sikrere backup – Alltid siste versjon installert Ulemper: – Ikke alltid gratis – Båndbredde kan være problem

Leverandører av katalogdata

        Biblioteksentralen – slik bibliotek vil ha dem Forlagsentralen – ofte raskest Nasjonalbiblioteket – "gratis" poster Bibsys – "gratis" poster for outsidere Samme arbeidet gjøres minst 3-4 ganger i Norge Dere bør ikke gjøre det enda en gang Internett – "gratis" poster Hvem har copyright til katalogposter?

Tenk økonomi og trivsel!

 BS og FS tilbyr integrert bokkjøp og overføring av katalogpost og eksemplaropplysninger.

 Mer enn halvparten av arbeidet spart ved å bruke ferdige katalogposter.

 Brukerne betaler for arbeidstiden din!

Forslag til videre lesning

        http://www.biblio-tech.com/ månedlig) http://www.ariadne.ac.uk/ kvartalsvis) (teknisk web-mag., (teknisk web-mag., http://www.libraryjournal.com

(generelt, 20 nr årlig) http://www.nb.no/html/postlister.html

(postlister) http://www.nb.no/ (Nasjonalbiblioteket) Norsk digitalt bibliotek http://www.nb.no/paradigma/ (Paradigme-prosjektet) http://www.mgmt.dal.ca/slis/etig/itcolumn/ITZ39.ht

m (Z39.50 in your library)

Leverandørene

     Biblioteksystemer http://www.bibits.no

http://www.bibliotekservice.no

http://www.bibsys.no

http://www.bibsyst.no

http://www.reindex.net

Katalogdata  http://www.bibsent.no/bibbi/side1.shtml

Alle bibliotekkataloger i landet http://www.nb.no/baser/bibliotek/

Standarder

    http://dublincore.org

http://www.loc.gov/marc/marc.html

http://www.loc.gov/marc/marcxml.html

http://www.w3.org/  http://www.nb.no/katkom/NORMARC/no rmarc.html

Forelesning 2: Hva alle bør ha

        Innkjøpssystem Katalogsystem m/autoritetsregister Utlånssystem Publikumssøk m/bestilling, melding på web Tidsskriftsystem Statistikk og rapportfunksjon enkel å bruke!

Sanntids oppdatering Filialhåndtering, konsortiehåndtering

Innkjøpssystem (Akkvisisjon)

 Innkjøpssystemet skal holde orden på – anskaffelsesønsker – bokvalg – ordre – oppfølging (purring etc) – mottak – mediebudsjett  Det bør ha mulighet for direkte kommunikasjon med leverandører

Innkjøp

       Valutahåndtering Leverandøropplysninger Bestille for andre bibliotek/filialer Håndtere flere konti – Vise forbruk/tilgjengelige midler grafisk Overføre penger mellom år Fordeling av budsjett over måneder – Forskellig mønster bøker/tidsskrifter Bruke EAN for å søke

Innkjøp

  Bøker som skal bestilles, må kunne reserveres Endring av eksemplarstatus – Setting av innstillinger for hvordan mottatte bøker skal behandles (innbinding, utlån etc).

Innkjøp

  Et innkjøpssystem er ikke et regnskapssystem, men kan likevel gi god økonomisk oversikt.

Egne regler for regnskapssystem

Katalogisering

  Det må kunne styres hva som skal autoriseres Katalogprogram må ha tilgang til – Bibliografiske data – Eksemplaropplysninger – Autoritetsfiler – Emneord – Klassifikasjonssystem

Katalogisering

  Autoritetsregistre må kunne oppdateres direkte fra katalogprogrammet Endring av autoritetsregistre bør ha en kontrollmekanisme som "Ønsker du virkelig å gjøre dette?".

– Globalt å bytte ut en term med en annen kan være risikabelt

Katalogisering

     Sømløs kopiering av eksterne poster Sømløs kommunikasjon m/Innkjøp Sømløs kommunikasjon m/Utlån og fjernlånsfunksjon Forhåndsvisning i ISBD/MARC, evt. andre standardformater Bør kunne velge hvilket format data skal lagres i og vises i

Katalogisering – søk

   Søking må kunne høyre-, venstre- og midttrunkeres Trunkeringstegn bør være valgfritt "Alt" bør være søkbart, også eksemplaropplysninger – Kommandosøk – Indeksblaing – Grafisk søk

Katalogisering

  Henvisninger må kunne håndteres direkte i katalogisering (autoritet) Søk på en form må gi treff på de andre formene – Eks.: Mumle Gåsegg må også gi treff på Johan Borgen

Katalogisering

    Katalogisering av flerbindsverk må være mulig og enkel å utføre Lenking mellom versjoner av et dokument bør være mulig Lenking av bind i flerbindsverk nødvendig FRBR Functional Requirements for Bibliographic Records   Hvis du er interessert i FRBR, se: http://folk.uio.no/knuthe/dok/frbr/datamining.pdf

Katalogstatistikk

      Årlig tilvekst Total samling Samlingens fordeling på fag, medietype, lånergrupper og filialer Tilvekstens fordeling på fag, medietype, lånergrupper og filialer Budsjettets fordeling på fag, medietype, lånergrupper og filialer Bibliotekmyndigheters krav

Søking

    Søking i samlingen bør være tilgjengelig fra alle større moduler Grensesnitt bør helst være nokså likt fra modul til modul Det bør være mulig å lagre søk Det bør være mulig å få personifiserte meldinger om nyheter

Utlån

      Registrere utlån og tilbakelevering – Varsel til skrankepersonale Reservere dokumenter Forhåndsreservere (booke) Fornye lån Purre/Rykke Reserveringsbrev/epost

Utlån

   Fleksibelt oppsett av utlånsbetingelser og overdagspenger Enkelt oppsett for når bibliotekets filialer er åpne Justere forfallsdato tilsvarende, slik at ikke bøker forfaller på dager biblioteket er stengt.

Utlån

  Utlån av elektroniske dokumenter er spesielt Bør elektroniske dokumenter tilbakeleveres?

– Hvis ikke, må dokumentet bli ubrukelig når lånetid er utløpt – Hvis ja, hva skiller det fra et vanlig lån?

Rapporter

 Det bør være enkelt å ta ut rapporter på – Ankomne reserveringer – Uavhentede reserveringer – Bøker som er/har vært reservert – Lånere som skylder penger – Lånere som er sperret – Bøker som skal flyttes – Eksemplarer med en bestemt status • Det bør være enkelt å modifisere rapporter og skape sine egne

Utlånsstatistikk 1

      Totalt antall lån i en gitt periode Lån fordelt på filial, lånergruppe, faggruppe, materialtype De mest utlånte titler (innkjøp) De minst utlånte titler (kassering) De mest aktive lånergrupper (ta hensyn til i mediebudsjett?) De minst aktive lånergrupper (markedsføring)

Utlånsstatistikk 2

    Statistikk bør lett la seg kopiere til andre programmer (tekstbehandling, regneark) Grafer bør produseres Bør kunne definere nye statistikker, for eksempel ved hjelp av SQL Bør tilfredsstille myndigheters krav

Utlån - Fjernlån

    Systemet bør håndtere både innlån fra andre bibliotek og utlån til andre bibliotek.

Bør håndtere kopier og elektroniske lån Bør gjøre bruk av nasjonale og internasjonale standarder I Norge: NILL og Base Bibliotek

Publikumssøk

       Skal være selv-instruerende Skal likevel ha kraftige søkemuligheter – Velge mellom ett eller flere-felt-skjerm, indeksblaing, grafisk søk Bør ha valgfritt språk Bør vise lenkede dokumenter (flerb.) Bør ha kart over biblioteket Et eksempel: Informatikkbiblioteket: http://www.ub.uio.no/umn/inf/kart/ifib.html

Publikumssøk

      Bør kunne reservere – også be om fjernlån Bør kunne se nyheter i biblioteket Bør kunne se de mest populære titler Bør kunne se egne lån Bør kunne avbestille reserveringer Bør kunne se tilknyttede dokumenter (både fulltekst og evt. lenkede referanser)

Publikumssøk og andre bibl.

  Andre bibliotek vil ønske å se MARC poster slik at de kan kopiere eller sjekke egen katalogisering Andre bibliotek vil ønske å be om fjernlån

Tidsskriftkontroll

     Heftekontroll Sirkulasjonskontroll Utsending av innholdsfortegnelse Tilgang til elektronisk tidsskrifthefte (kan også plasseres andre steder i systemet) Varsling om nye hefter for tidsskrifter innen låners interessefelt

Tidsskriftkontroll

    Utgivelsesmønstre varierer System må være fleksibelt System kan bli svært komplisert Avhengig av god datamodell og planlegging

Oppetid

 Systemets oppetid – Må være oppe så lenge biblioteket er åpent – Bør være oppe 24t x 7  Brukerstøtte bør være tilgjengelig i bibliotekets åpningstid

Sikkerhet 1

  Databasen må ikke være fysisk tilgjengelig for alle brukere – ODBC er en måte å oppnå dette på (Open Database Connection) Databasen må ha muligheter for selv reparasjon ved f.eks. strømbrudd.

– Checkpoints , rollback – Loggfiler – Speiling

Sikkerhet 2

  Forskjellige brukergrupper må kunne settes opp med forskjellige adgangsnivåer Bibliotek i konsortier bør ikke se hverandres utlånsdata

Dette er ingen spesifikasjon

   Forelesningsnotatene fra denne og forrige forelesning er kun en generell innføring, de er ingen kravspesifikasjon Mange institusjoner har laget svært detaljerte krav, mange av dem kan gjenbrukes!

Ikke sikkert at du finner et system som tilfredsstiller ALLE kravene – må veie krav mot hverandre