Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere. Informasjon om produkter og tjenester på visitnorway.com blir levert fra flere forskjellige leverandører. Disse leverer data på forskjellige formater og strukturer, dette fører til at produkter fra hver enkelt leverandør må behandles på en egen måte ettersom det ikke er noen felles struktur på produktene fra de ulike leverandørene. Denne kravspesifikasjonen beskriver hvordan et system skal hente inn og konvertere data fra ulike kilder til en felles datamodell, lagre dataene og gjøre informasjonen tilgjengelig via et API. Leserveiledning Denne kravspesifikasjonen består av en innledning til hvem studentene bak prosjektet er, litt om oppdragsgiver og oppgaven vi fikk utdelt. Videre gjør vi rede for de ramme- og systemkrav som denne oppgaven krevde. 2
Innhold Forord 2 Leserveiledning 2 Innhold 3 1 Innledning 4 1.1 Bedriften og oppgaven 4 1.1.1 Gruppen 4 1.1.2 Oppdragsgiver 4 1.1.3 Kunde 4 1.1.4 Oppgaven: Produktkvalitet, Visit Norway 4 1.1.5 Avgrensning av oppgaven: mål og rammebetingelser 5 2 Systemkrav 7 2.1 Innhenting, konvertering og persistering 7 2.1.1 Systemet skal kunne 7 2.2 API 7 2.2.1 API-et skal 7 2.2.2 En API-konsument skal kunne 7 3 Rammekrav 8 3.1 API-nøkler 8 3.2 Krav fra produktleverandører 8 3.3 Brukergruppe 8 3.4 Brukervennlighet 8 3.5 Vedlikehold 8 3.6 Hurtighet 9 3.7 Sikkerhet 9 3.8 Fremtidig utvidelse 9 3
1 Innledning 1.1 Bedriften og oppgaven 1.1.1 Gruppen Gruppen består av Christina Kihlstrøm, Michael Arvanitidis og Gry Siri Eggen. Medlemmene har jobbet sammen tidligere, og kjenner til hverandres styrker og svakheter. Gruppen fant sammen på bakgrunn av gode erfaringer fra tidligere samarbeider, samt felles interesse for hva oppgaven skulle inneholde. 1.1.2 Oppdragsgiver Creuna er Nordens største digitale byrå med over 300 medarbeidere. De kombinerer strategi, design og teknologi for å skape spennende og innovative løsninger, og har hovedkontor på Skøyen i Oslo. Creuna stiller til disposisjon all program- og maskinvare som trengs for å gjennomføre prosjektet, samt to veiledere; Christian Hochlin og Pelle Bjerkestrand. 1.1.3 Kunde Kunden i dette prosjektet er Innovasjon Norge, som eier Visit Norway (www.visitnorway.com). Innovasjon Norge arbeider for å profilere norsk næringsliv og Norge som reisemål, og har som visjon å gi lokale ideer globale muligheter. På Visit Norway, som er Innovasjon Norges turistinformasjonsside og Norges offisielle reiseguide på nett, presenteres informasjon om lokale virksomheter rundt om i hele Norge. Creuna overtok ansvaret for og videreutvikling av Visit Norway i 2013. Gruppen vil ikke ha noen direkte kontakt med kunden gjennom dette prosjektet; alt foregår via oppdragsgiver. 1.1.4 Oppgaven: Produktkvalitet, Visit Norway Visit Norway er en av Norges mest besøkte nettsider, og den baserer seg på at lokale virksomheter landet rundt selv produserer presentasjonsmateriale. Innovasjon Norge og Visit Norway fikk tidligere all produktinformasjon fra én ekstern leverandør. Produkter i denne sammenhengen omfatter alt av aktiviteter, arrangementer, hotellopphold, utflukter og lignende som er tilgjengelige via Visit Norway. Disse produktene har forskjellige produkteiere og blir levert gjennom en produktleverandør. Visit Norway har nå fått flere produktleverandører å forholde 4
seg til, og ønsker å standardisere formatet på produktdataene som mottas for å lettere kunne håndtere og presentere forskjellige produkter fra forskjellige kilder på likt vis. All relevant produktdata som hentes fra produktleverandørene, ønskes samlet i ett system, som deretter kan være kilde for både nettstedet Visit Norway, Visit Norway-mobilapplikasjon og eventuelt andre eksterne og interne systemer. Prosjektet i sin helhet vil ha behov for Ny domenemodell for produkter Systemarkitektur Persisteringsløsning Produkt-API Integrasjon mot eksisterende løsning Klient for administrasjon av produktdata Sluttbrukerklient for presentasjon av produktdata 1.1.5 Avgrensning av oppgaven: mål og rammebetingelser I samarbeid med oppdragsgiver har vi avgrenset oppgaven noe, basert på tiden vi har til rådighet. Sammen har vi satt følgende mål: en ny domenemodell for produkter, konvertering av produktdataene fra leverandørene, en persisteringsløsning og et produkt-api. Oppdragsgiver er åpen for undersøkelser rundt og bruk av alternative rammeverk, plattformer og produkter, og kunden, Innovasjon Norge, kan tenke seg å ha et åpent API. Vi velger derfor å la noe av valget rundt teknologier skje under selve prosessen. Systemet skal Hente produktdata fra leverandørene Omgjøre produktdata i henhold til den interne domenemodellen Lagre dataene Gjøre datasettet tilgjengelig via et API 5
Systemet bør Ha en domenemodell som først og fremst er basert på den produktinformasjonen som leverandørene har til felles, for å unngå for mye hull i dataene, men også utfordre leverandørene til å levere bedre produktdata Kunne kjøres automatisk Legge til rette for ulik bruk av API-et, utover nettstedet Visit Norway 6
2 Systemkrav 2.1 Innhenting, konvertering og persistering 2.1.1 Systemet skal kunne Automatisk hente inn produkter fra flere leverandører Konvertere innhentet data til ny domenemodell Lagre i database Slette oppføringer fra databasen Oppdatere alle felt i et objekt, og alle tilhørende entiteter Beholde et objekts id ved oppdatering Loggføre aktivitet og feil 2.2 API 2.2.1 API-et skal Støtte OData Gi ut data som JSON-objekter Ha en responstid på maks to sekunder ved henting av ett produkt 2.2.2 En API-konsument skal kunne Hente ut alle produkter på ett språk Hente ut alle produkter i et område på ett språk Hente ut alle produkter i nærheten av konsumenten på ett språk Hente ut et bestemt produkt på ett språk Hente ut alle lokale organisasjoner Hente ut alle produkter i en lokal organisasjon på ett språk Hente ut alle produkter i en bestemt kategori på ett språk Hente ut et produkt på flere forskjellige språk ved å bruke samme produkt-id 7
3 Rammekrav 3.1 API-nøkler For å kunne hente inn informasjon fra Tellus og CBIS kreves gyldige API-nøkler. Studentene har ansvar for å sørge for at disse ikke kommer på avveie. Nøkkelen skal fjernes fra alle dokumenter som leveres inn, samt sensureres i eventuelle skjermbilder det skulle forekomme i. 3.2 Krav fra produktleverandører Ved bruk av Tellus API, kreves det at ved oppdatering av et produkt, skal alle data overskrives, og alle produkter skal oppdateres og overskrives en gang i måneden. Innhenting av data skal kun skje mellom 00.00 og 07.00 CET. 3.3 Brukergruppe API-et kan brukes av utviklere i forbindelse med Visit Norway, både nettside og app. Kunden kunne tenke seg å ha et åpent API, noe som vil si at API-et bør følge bransjestandarder og være lettforståelig. 3.4 Brukervennlighet Klasse- og variabelnavn skal være selvforklarende og på engelsk, og API-et skal følge URLstandarder (API/Controller/parameter/eventuelt flere parametere). API-et skal være relativt raskt, slik at det kan benyttes av klienter direkte. 3.5 Vedlikehold Systemet skal være oversiktlig, logisk oppbygd og enkelt å vedlikeholde. For at andre utviklere enkelt skal kunne sette seg inn i de ulike delene av kildekoden, skal koden være strukturert, alle navn på funksjoner og variabler skal være logiske, og produktet skal være godt dokumentert. 8
3.6 Hurtighet Systemet skal være effektivt med tanke på konvertering, lagring og presentering av data. 3.7 Sikkerhet Det er ikke noe krav om sikkerhet fra oppdragsgiver, da dette håndteres på andre plan. 3.8 Fremtidig utvidelse Systemet skal enkelt kunne utvides for å legge til flere produktleverandører om det skulle bli aktuelt på et senere tidspunkt. Metoder for innhenting og konvertering vil variere fra leverandør til leverandør, men den interne modellen for produkter skal forbli lik. Systemet skal lagdeles og bygges opp på en slik måte at endringer og tillegg enkelt kan integreres. Dersom en del skal utvides, kan den delen forandres på uten at det påvirker andre lags funksjoner. 9