Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Like dokumenter
Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Hovedprosjekt våren 2007

1 Forord. Kravspesifikasjon

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

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

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

Kravspesifikasjon MetaView

PROSESSDOKUMENTASJON

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Kravspesifikasjon Gruppe nr ABTF

Kravspesifikasjon. Forord

Produktrapport. Hovedprosjekt ved Høgskolen i Oslo

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Pillbox Punchline

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Produktrapport Gruppe 9

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Prosessrapport. Hovedprosjekt ved Høgskolen i Oslo. Våren 2008

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Testsituasjon Resultat Kommentar. Fungerer som det skal!

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

Del VII: Kravspesifikasjon

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8

HOVEDPROSJEKT HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

Bachelorprosjekt 2015

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport

2/3/2014 INSTITUTT FOR FÔRIT CDS INFORMASJONSTEKNOLOGI, HØGSKOLEN I OSLO OG AKERSHUS. Shahariar Kabir Bhuiyan

Forprosjektrapport. Gruppe Januar 2016

Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

Kravspesifikasjon

Kravspesifikasjon Innholdsfortegnelse

Kravspesifikasjonsrapport

Testdokumentasjon Presentasjon

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

VEDLEGG 1 KRAVSPESIFIKASJON

Bachelorprosjekt i informasjonsteknologi, vår 2017

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender

KRAVSPESIFIKASJON v.1.2

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Forprosjekt for Accentures Overvåkningssystem

Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg.

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

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen.

KRAVSPESIFIKASJON FORORD

Granitt Grafisk AS Kravspesifikasjon Gruppenr:

Vårt system kan kjøres ved å skrive. STUD1 konto fredo 37 (holdeplass)

Forprosjekt. Høgskolen i Oslo, våren

1. Forord Innholdsfortegnelse innledning Funksjonelle egenskaper og krav Spesifikke krav av delsystemer...

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

Forprosjektrapport for bacheloroppgave i data og informasjonsteknologi

Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018

HOVEDPROSJEKT I DATA VÅR 2011

Innhold Forord...3 Begreper og akronymer...4 Systembeskrivelse...5 Generelt...5 Funksjonelle krav...7 Ikke-Funksjonelle krav...9 Prioritering...

4.1. Kravspesifikasjon

Innholdsfortegnelse. 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10

Repository Self Service. Hovedoppgave våren 2010

Kravspesifikasjon. Forord

Båtforening på nett. Produktrapport

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Avslutning

Presentasjon av bachelorprosjekt 2009/2010 for Morten Hegstad og Kim Lilleberg. Prosjektnummer 2E

Teknostorage - Lagersystem. Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. 3. januar 2012 til 11.

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

1. Forord 2. Leserveiledning

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Databaser og moderne systemutvikling - dag én

Forprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Entobutikk 1.KRAVSPESIFIKASJON VÅR 2011

S y s t e m d o k u m e n t a s j o n

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Forprosjektrapport ElevApp

Prosjektdagbok hovedprosjekt våren 09

Dagbok. Januar. Uke 2 ( ) Uke 3 ( ) Uke 3 (17.01, 12:45-14:00)

Forprosjektrapport. Gruppemedlemmer: Maud Veronica Gine Lundh - s Noha Xue - s Ketil Øvrebø - s Even Geithus Øwre - s171663

KRAVSPESIFIKASJON. Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB. Prosjektperiode: 4. januar mai 2010

Studentdrevet innovasjon

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

1. Introduksjon. Glis 13/02/2018

Gruppenavn. Beskrivelse av arkitektur For Navn på systemet. Versjon <1.0>

Kapittel 13 Advanced Hypertext Implementation. Martin Lie Ole Kristian Heggøy

Testrapport Prosjekt nr Det Norske Veritas

Gruppe Forprosjekt. Gruppe 15

Styringsdokumenter. Forord

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Web Service Registry

Use Case Modeller. Administrator og standardbruker

Dokument 1 - Sammendrag

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON

Entobutikk FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus,

Transkript:

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument under hele prosjektperioden mellom oppdragsgiver og prosjektgruppa. Det fungerer også som en rettesnor for utviklingen av prosjektet. I ettertid kan kravene endre seg derfor skal vi sørge for å gjøre siste endringer i kravspesifikasjonen i slutten av prosjektet.

2. Innholdsfortegnelse 1. Forord...2 2. Innholdsfortegnelse...3 3. Presentasjon...4 4. Bedriften...5 5. Systemet...5 5.1 Hendelsesdiagram(artikelen ligger i cache databasen)...5 5.2 Hendelsesdiagram(artikelen ligger ikke i cache databasen)...6 5.3 Systembeskrivelse...6 5.4 Arkitekturdiagram av systemet...7 6. Databasen...7 7. Systemets krav...8 7.1 Funksjonelle krav-bruker...8 7.2 Funksjonelle krav-administrator...9 7.3. Funksjonelle krav-metagen system...9 7.4 Funksjonelle krav-rammeverket...9 7.5 Ikke funksjonelle krav...9 7.6. Tekniske krav...10 7.7. Krav til kode...10 8. Datasikring...10 9. Begrensninger...10 10. Grensesnitt...11 11. Krav til design...11 12. Krav til søkemotor...11 13. Fremtidig utvidelse av systemet...11 14. Arbeids metode...11 14.1 Scrum Prosess skisse...12 15. Krav til dokumentasjon...12

3. Presentasjon Prosjekt tittel: Prosjektperiode: MetaGen 7.jan til 23. Mai Prosjektgruppe: Karen Arrendondo, Fadima Mohamoud, Orji Okoroafor og Ole Myrbakken. Oppgave: System for kryssreferanser av metainformasjon med tema mot politikk/stortinget. Oppdragsgiver: Kontaktperson i API: Veileder ved HiO: A-Pressen Interaktiv AS (API) Jørgen Wahlberg Eva Hadler Vihovde

4. Bedriften API drifter, utvikler og administrerer et nettverk av 56 nettaviser, 20 wapaviser og streamingtjenester for lokaltv og lokalradio. API er eid av A-pressen, men leverer også tjenester til medier utenfor konsernet. I dagens situasjon har A-Pressen lignende system for fotball og er interesserte i å få flere av slike systemer. Hensikten med MetaGen systemet er at det skal kunne være mulig for en som skriver artikkel å få tak i tilleggsinformasjon som er relatert til innholdet uten å gjøre ekstra arbeid. Dette bedrer kvaliteten av artikkelen samtidig leseren for ekstra informasjon som kan være relevant til innholdet. 5. Systemet I dette punktet vil vi illustrere systemet vårt ved hjelp av to hendelsesdiagrammer, en arkitektur skisse og to ER-diagrammer. 5.1 Hendelsesdiagram (artikkelen ligger i cache databasen) Hendelsesdiagrammet viser flyten i MetaGen.

5.2 Hendelsesdiagram (artikkelen ligger ikke i cache databasen) 5.3 Systembeskrivelse Vi skal i dette prosjektet utvikle et system for kryssreferanser av metainformasjon. Systemet skal automatisk generere tillegginformasjon av artikler basert på innhold. Tillegginformasjon kan enten være ekstra informasjon om innholdet eller referanser til andre artikler basert på relatert informasjon. Bruker som skriver en artikkel skal kunne sende en forespørsel med en url adresse til en ekstern nettavis system via en http protokoll. Nettavisen mottar forespørselen og sender artikkeliden videre til MetaGen systemet. Kommunikasjonen mellom nettavisen og MetaGen skal også foregå i http protokollet og måten vi har tenkt å ta i bruk kommunikasjonen kalles REST API. I vårt tilfelle er det nok med et objekt som skal sende en forespørsel om en artikkelid eller flere samtidig, uten at systemet krasjer og en forespørsel om metainformasjon. Ved slik kan systemet også oppdatere nye artikkelid. Når MetaGen mottar forespørselen sjekker den artikkeliden mot cashe databasen om den finnes fra før av og hvis det stemmer overens sendes informasjonen tilbake til nettavisen. Deretter omgjør systemet informasjonen til en xml format fil og sender den avgårde. Forespørslen skal inneholde all informasjon som er relatert til artikkelen som skrives. Til slutt generer nettavisen informasjonen fra MetaGen til en html side og returnerer den tilbake til brukeren. Hvis systemet ikke finner artikkeliden skal systemet sende en forsepørsel til nettavisen om en xml representasjon av artikkelen. Deretter skal MetaGen sørge for xml representasjonen blir parset til java og settes inn i nye java objekter og det er her spring rammeverket kommer i bildet. Systemet skal benyttes av Spring rammeverket siden den enklere gjør bruken av Hibernate og koblingene mellom objektene. Systemet skal også ta i bruk ormen Hibernate for kommunikasjonen mellom javaobjektene og databasen. I vårt tilfelle velger vi å dele opp Mysql databasen i to for å få bedre oversikt over metainformasjon og referanseinfo. Prosjetgruppen velger å kalle det cashe databasen og MetaGen database som er egentlig den samme databasen. Forskjellen er at cashe

databasen skal inneholde all referanseinfoen til artikkelen, og i MetaGen databasen skal det inneholde metainformasjon om Stortinget. Systemet skal kunne søke etter informasjon i MetaGen databasen ved hjelp av nøkkelord. Deretter få opp informasjon fra MetaGen databasen. Resultatet av koblingen mellom javaobjektene og databasen inneholder referanseinfo som skal lagres i cashe databasen. MetaGen sender nå all tilleggsinformasjonen tilbake til nettavis via en xml format fil. Prosjektgruppen skal også utvikle i tillegg en seperat brukergrensesnitt for manuell overstyring og administrasjon av selve systemet. 5.4 Arkitekturdiagram av systemet Arkitekturdiagrammet viser relasjonene mellom de forskjellige delene i MetaGen og omgivelsen rundt MetaGen. 6. Databasen I første omgang har gruppen og arbeidsgiveren API blitt enige om å ta får oss temaet Stortinget. Når det gjelder MetaGen databasen er vi litt usiker på hvor mye informasjon som skal settes inn, men her kommer det to ER-diagrammer som skal illustrerer hvordan vi har tenkt oss koblingen mellom de forskjellige tabellene.

ER-diagram for Metagen databasen ER-diagram for Cache databasen 7. Systemets krav 7.1 Funksjonelle krav bruker Her kommer de funksjonelle kravene brukeren har i MetaGen systemet. Disse kravene ble bestem av vår arbeidsgiver API. En bruker skal kunne ha tilgang til å kommunisere med en nettavis.

Brukeren skal kunne ha tilgang til å sende en forespørsel med en url adresse til en nettavis og motta et svar fra nettavisen. 7.2 Funksjonelle krav administrator Her kommer de funksjonelle kravene administratoren har i MetaGen systemet. Disse kravene ble bestem av vår arbeidsgiver API. En administrator skal kunne ha tilgang til å administrere systemet gjennom en brukervennlig grensesnitt. En administrator skal kunne administrere kommunikasjonen mellom MetaGen og nettavisen. En administrator skal kunne også legge til, fjerne eller utvide innholdet i databasen ved behov. 7.3 Funksjonelle krav MetaGen system Her kommer de funksjonelle kravene til selve MetaGen systemet. Disse kravene ble bestem av vår arbeidsgiver API. MetaGen skal kunne ta imot en forespørsel fra ekstern systemer(nettaviser) med en artikkel id og sjekke det mot cashe databasen om den finnes fra før av. Hvis artikkel iden finnes fra før av skal MetaGen kunne hente ut all informasjonen som er relatert til innholdet fra MetaGen databasen. MetaGen systemet skal også ha muligheten til å sette sammen informasjonen til en xml format og sende deretter det av gårde til nettavisen. Hvis artikkel iden ikke finnes fra før av skal MetaGen kunne hente en xml representasjon av artikkelen. Systemet skal sjekke om informasjonen finnes fra før av og deretter sende avgårde en xml format fil til nettavisen. 7.4 Funksjonelle krav rammeverket Her kommer de funksjonelle kravene rammeverket har i MetaGen systemet. Disse kravene ble bestem av vår arbeidsgiveren API. Det skal brukes en orm teknologi(object-relational Mapping) som heter hibernate. Rammeverket skal kjøre Tomcat. Rammeverket skal utvides i Eclipse. Rammeverket skal støtte SCRUM. Subversion skal brukes til verson håndtering. 7.5 Ikke funksjonelle krav Her kommer de funksjonelle kravene brukeren har i systemet. Kravene ble bestem av vår arbeidsgiveren API. Bortsett fra dokumenasjon skal være på bokmål og kommentarene skal være på engelsk, disse valgte gruppen som krav. Gruppen velger å skrive all dokumentasjon på bokmål pga. all dokumentasjon blir vurdert av norsk talende sensor, og gruppen skal bruke dokumentasjonen under veis, dermed blir det best å bruke bokmål. Gruppen velger å ha all kommentar på engelsk siden det skal være mulighet å vidreutvikle systemet i et senere tidspunkt, dermed er det best å forsikre seg at

programutvikleren skjønner språket. All dokumentasjon av Metagen skal skrives på bokmål. Det skal benyttes Unit-testing under utviklingen av progammet. All kode kommentarer og attributter skal være på engelsk. Webgrensesnittet skal være på norsk, men flere språk kan implementeres i et senere tidspunkt. Programmet skal kunne returnere metainfo om artikkelen relativt raskt. Metainformasjonen som returneres skal ha en relasjon til artikkelen. Metainformasjonen som returneres skal ha en relasjon til Stortinget. Resten av kravene som kommer ble bestem av vår arbeidsgiver API. 7.6 Tekniske krav Prosjektet skal implementeres i Spring rammeverket. Metagen systemet skal programmeres i java. Hibernate skal brukes til kommunikasjonen mellom javaobjektene og databasen. Metagen prosjektet skal bygges opp av Maven. Systemet skal ta i bruk MYSQL databasen. Unitesting skal tas i bruk for testingen av systemet. 7.7 Krav til kode Det stilles krav at prosjektgruppen bruker unitesting under utviklingsperioden. Det stilles også krav at javakoden innholder gode kommentarer. Prosjektgruppen ønsker å skille ren java-kode og koding for design ved hjelp av javabønner. Vi ønsker å følge Java kode standard som for eksempel alle klassenavn skrives med stor forbokstav og resten med små bokstaver og variabler begynner med liten forbokstav etc. 8. Datasikring Det stilles krav at det ikke blir dobbeltlagring av informasjon. Prosjektgruppen setter krav til å ha backup av selve systemet,dokumenter etc. Det stilles krav til administrator å ha passord og brukernavn for tilgang av grensesnittet av administreringen av systemet. 9.Begrensninger Infomasjonen som skal sendes tilbake til nettavisen og skal være av typen xml fil. Det er ikke satt krav for hvor stort belastning databasen skal ha, vi velger å begrense det i første omgang til metainformasjon om Stortinget.

10. Grensesnitt Oppdragsgiveren har ikke noen spesielle krav om hvordan brukergrensenittet skal fungere, men prosjektgruppen og API-Pressen er enige med funksjonene som trengs i grensesnittet. 11. Krav til design Det er ingen krav til designet av grensesnittet. Det er krav til brukervennlig grensesnitt. 12. Krav til søkemotor Søkermotoren skal enkelt kunne søke etter informasjon ved hjelp av nøkleord. I vårt system ønsker vi at systemet skal for eksempel søke etter navn på stortingsrepresentant, partier, partigrupper, fylker etc. i databasen. Ved hjelp av gode nøkleord blir det enklere å få tak i informasjon og søkemotorens effektivitet blir bedre. 13. Fremtidig utvidelse av systemet Det skal kunne være mulighet for API-Pressen å utvide systemet i senere tidspunkt enten ved å gjøre det mer avansert eller legge til nye løsninger. Derfor er det viktig at prosjektgruppen utvikler systemet slik at det blir enklere å videre utvikle det i et senere tidspunkt. Dette forusetter også at det foreligger en god og ryddig dokumentasjon som lett kan beskrive system i sin helhet. 14. Arbeids metode Prosjektgruppen har tenkt å ta i bruk prosessmodellen scrum som er en smidig prosessmodell som tar for seg prosjetstyring og prosjektkontroll. Gruppen velger å dele arbeide opp i forskjellige sprinter. Hver sprint består av et planleggingsmøte der vi velger et tema som vi skal jobbe med til neste sprint. I begynnelsen av hvert sprintmøte så forteller hvert enkelt gruppemedlem hva den har jobbet med fra forrige sprint, og hvilken utfordringer den eventuelt har hatt. Gruppen møtes hver tirsdag og fredag og har hyppig kontakt via msn. Dette er for å kvalitet sikre fremdrift i prosjket. Videre så møter vi vår faglig veileder en gang i uken og har avtalte møter med API-Pressen etter behov. Gruppen har også opprettet en Sprint backlog der vi har lagd en liste over ting som må gjøre med hensyn til arbeidsgiverens ønsker og forespørsler. Disse arbeids oppgavene blir igjen delt opp i de forskjellig sprintene som er forklart ovenfor.

14.1 Scrum Prosses Skisse: 15. Krav til dokumentasjon A-pressen skal kunne ha muligheten til å videreutvikle MetaGen systemet. Derfor stilles det krav til god dokumentasjon av både produktrapport og prosessrapport. Det stilles også krav at man skal føre prosjektdagbok under hele prosjekt perioden. Gruppen skal satse på å skrive en god dokumentasjon slik at når sensor eller A- pressen leser dokumentasjonen skal de skjønne hva systemet går ut på.dette vil gjøre det enklere for A-pressen å gjøre nødvendige endringer i et senere tidspunkt.