Tetriz - Event & Management

Transkript

1 Tetriz - Event & Management Artistnettside Kravspesifikasjon HØGSKOLEN I OSLO OG AKERSHUS Hovedprosjekt GRUPPE 7 Jasmin Mehrnia, Joakim Kartveit, Frode Mathiesen, Gry Anita Nilsen

2 Forord En kravspesifikasjon skal beskrive oppdragsgiverens krav til det som skal utvikles. Produkttypen skal beskrives og prosjektet skal spesifiseres i detalj. En kravspesifikasjon er et gjennomgående dokument i løpet av prosjektet, som skal fungere som en rettesnor for utviklerne. Det er en del av styringsdokumentene, samtidig som det er en del av sluttdokumentasjonen. Den fungerer som en bindende avtale mellom utviklerne og oppdragsgiver, men også kravene fra Høgskolen i Oslo og Akershus skal tas i betraktning. Hensikten med kravspesifikasjonen er at den skal sikre en felles enighet om hva som skal utvikles, samt en god dialog mellom partene og gi utviklerne en god pekepinn om hvilket sluttprodukt som er ønskelig. Vårt hovedmål er å gi bedriften et sluttprodukt de er fornøyd med, et mål som vi vil kunne oppnå blant annet ved å følge kravspesifikasjonen. Kravspesifikasjonen er beregnet både for oss som utviklere og bedriften, som vil være med på å skape en trygghet om at målene fra bedriften blir innfridd. Leserveiledning I denne kravspesifikasjonen vil først de ulike partene bli presentert, bakgrunn for prosjektet, samt en kort systembeskrivelse. Etter dette vil vi ta for oss sidestruktur, funksjonelle krav, ikke-funksjonelle krav, logisk datamodell og eksterne krav. Det siste denne kravspesifikasjonen inneholder er endringer/og eller feil som oppstod underveis. 2

3 1. Innholdsfortegnelse Forord... 2 Leserveiledning Presentasjon Gruppen Oppdragsgiveren Veileder og institusjon Bakgrunn for oppgaven Kort systembeskrivelse Mål Rammebetingelser Sidestruktur Funksjonelle krav Prioritert funksjonalitet Ønsket funksjonalitet/tilleggsfunksjonalitet Beskrivelse til tabell 1 og Tabell 1, funksjonelle krav med prioritet Tabell 2, funksjonelle krav med prioritet 2 og Ikke-funksjonelle krav Brukervennlighet Leveransekrav Krav til standarder Tabell med oversikt over ikke-funksjonelle krav Logisk datamodell (E/R modell) Eksterne krav Estetiske krav Lovmessige krav Opphavsrett Designretten Personvernloven Diskriminerings- og tilgjengelighetsloven Endringshåndtering Krav ved forslag til endringer Feilhåndtering Referanseliste Vedlegg

4 1. Presentasjon Punkt 1. gir en kort presentasjon av de ulike partene i prosjektet. 1.1 Gruppen Gruppen (nr.7) består av Joakim Kartveit, Frode Mathiesen, Jasmin Mehrnia og Gry Anita Nilsen. Samtlige studerer Bachelor i Anvendt Datateknologi ved Høgskolen i Oslo og Akershus, alle har jobbet med minst en på gruppen tidligere, vi vet derfor hvilke forventninger vi har til hverandre og en felles enighet om ambisjoner og mål. 1.2 Oppdragsgiveren Vår oppdragsgiver er Tetriz Event & Management. Denne bedriften hadde oppstart i august 2012 og har sitt kontor i Oslo. Tetriz er en bedrift som har ansvar for artister, der deres hovedansvar er å promotere sine artister. Bedriften er også en leverandør innen booking, eventer og management. De leverer eventer til små, mellomstore og store bedrifter. Kontaktpersonen vi skal forholde oss til er Daniel Hamnes (CEO/daglig leder). 1.3 Veileder og institusjon Hovedprosjektet utføres ved fakultetet for Teknologi, Kunst og Design (TKD), Anvendt Datateknologi ved Oslo og Akershus. Vår interne veileder ved Høgskolen er Geir Skjevling. 4

5 2. Bakgrunn for oppgaven Vi har inngått en avtale med Tetriz Event & Management, som ønsker en promoteringsplattform for sine artister, vi skal utvikle en mal for denne plattformen med tilhørende publiseringsverktøy, dette vil være basert på artisten Daniel Elmrhari. Bedriften skal selv kunne bruke denne «malen» for å opprette nye nettsider for sine artister, det skal i tillegg være mulig for bedriften å holde nettsiden oppdatert, ved å kunne legge til og endre informasjon, nyheter, bilder, sangtekster og videoer på nettsiden. 5

6 3. Kort systembeskrivelse Det skal utvikles en nettside ut ifra en av deres artister, Daniel Elmrhari. Nettsiden skal vise artistens nyheter, biografi, bilder, videoer, sangtekster, konserter og kontaktinformasjon. Under kontaktinformasjon er det ønskelig at brukere skal kunne melde seg opp til nyhetsbrev. Det skal også være bookinginformasjon på nettsiden. Nettsiden skal ha en oversiktlig presentasjon med et rent innbydende design, som oppdragsgiver skal godkjenne. Oppdragsgiver har også gitt oss eksempler på nettside design som de ønsker at vi skal hente inspirasjon fra, se referanse nr. 5-1, 5-2 og 5-3. Tetriz har kjøpt domenenavn for artistene, serverplass for nettsidene vil leies når dette behovet oppstår. Produktet skal være en nettside for Daniel Elmrhari, som skal promotere artisten og gjøre det lettere for hans tilhengere å få informasjon om han. Nettsiden skal være tilgjengelig på to språk; Norsk og Engelsk. 3.1 Mål Utvikle en nettside for promotering av en artist Forenkle tilgang til informasjon/nyheter om artisten for tilhengere Nettsiden skal være tilgjengelig for et bredt publikum Lett resirkulasjon/gjenbruk av malen, slik at bedriften kan bruke denne videre Forenkle prosessen med å legge til/slette informasjon, bilder, videoer og filer. 3.2 Rammebetingelser Fungere på alle nettlesere Fungere på pc, Mac, ipad og alle smarttelefoner Tilgjengelig på to språk; Norsk og Engelsk Oppdragsgiver/bedriften bør ha mulighet til å sende ut nyhetsbrev fra nettsiden 6

7 4. Sidestruktur Oppdragsgiver har gitt en oversikt over ønskede menyalternativer, vårt forslag til sidestruktur ut fra dette vises under, figur 5-1. Figur 5-1: Sidestruktur til nettsiden 7

8 5. Funksjonelle krav Funksjonelle krav forteller hva systemet skal gjøre, hvilke funksjoner/tjenester som skal være tilgjengelig og hvordan systemet skal respondere på brukernes input. Selve hensikten med de funksjonelle kravene er at de skal forklare hva systemet skal utføre, samtidig som de også vil være med på å produsere eller begrense et resultat. Et godt funksjonelt krav bør være presist, komplett og forenlig. Vi har valgt å dele inn funksjonelle krav i tre ulike grupper; 1.nødvendige krav (må), 2.krav som bør være med og 3.ønskelige krav. Punkt 5.1 Prioritert funksjonalitet vil ta for seg kravene som vi må og bør implementere i systemet, som vi anser som nødvendig for å nå målene og hensikten med oppgaven. Punkt 5.2 Ønsket funksjonalitet/tilleggsfunksjonalitet vil ta for seg kravene vi ikke anser som nødvendig og/eller krav fra oppdragsgiver som vi ikke anser som «gode» løsninger. Under punkt 5.2 vil vi også ta for oss krav vi ønsker å få til dersom vi blir ferdig med de prioriterte kravene tidligere enn antatt, og/eller har tid til å legge til mer funksjonalitet. Se punkt 5.1 og 5.2 for forklaring av de ulike kravene, punkt 5.3 for beskrivelse av tabeller, punkt Tabell 1, funksjonelle krav med prioritet 1 og punkt Tabell 2, funksjonelle krav med prioritet 2 og Prioritert funksjonalitet 1. Nødvendige krav: Disse kravene må implementeres i den ferdige løsningen, og er grunnleggende for at systemet skal fungere. Krav innfris så tidlig som mulig. Disse vil ha prioritet nr Krav som bør være med: Disse kravene ses på som viktige krav, som bør være med i den ferdige løsningen, dette for at produktet skal fungere optimalt. Disse vil ha prioritert nr Ønsket funksjonalitet/tilleggsfunksjonalitet 3. Ønskelige krav: 8

9 Kravene kan innfris i løsningen, men de er ikke nødvendige for at systemet skal fungere optimalt. Dette er ikke krav som må innfris, ettersom de spiller en mindre sentral rolle i produktet. Disse vil ha prioritert nr Beskrivelse til tabell 1 og 2 Beskrivelse til tabell: A-bruker: Dette er en bruker som er systemadministrator, den skal kunne bestemme hvem som blir opprettet/deaktivert, og denne brukeren har alle rettigheter. B-bruker: Dette er en bruker som er innlogget i systemet, dens oppgave er å legge inn informasjon og oppdatere nettsiden. Denne brukeren har noen rettigheter men ikke alle som A-bruker har. C-bruker: Dette er en bruker som ikke er innlogget, som kun ønsker å besøke nettsiden. 9

10 5.3.1 Tabell 1, funksjonelle krav med prioritet 1 Beskrivelse Akseptansekrav Prioritet Opprette nye brukere A-bruker må kunne opprette 1 nye brukere Deaktivere/slette brukere A-bruker må kunne deaktivere/ 1 slette B-brukere, slik at B-brukeren ikke har tilgang til innhold eller mulighet til å endre nettsiden Resonsiv på enheter Løsningen må fungere på pc, mac, 1 smarttelefon og tablet Resonsiv på nettlesere Løsningen skal fungere på alle 1 nettlesere Tilgjengelig på to språk Nettsiden og CMS skal være 1 tilgjengelig på norsk og engelsk Laste opp/publisere B-bruker må kunne laste opp/ 1 nyhetsartikkel publisere nyhetsartikkel som publiseres på nettsiden Slette nyhetsartikkel B-bruker må kunne slette 1 nyhetsartikkel fra nettsiden Laste opp media B-bruker må kunne laste opp 1 media (bilde, video, sangtekst) som publiseres på nettsiden Slette media B-bruker må kunne slette media 1 (bilde, video, sangtekst) fra nettsiden Snarveier til sosiale medier C-bruker må kunne trykke på 1 ikoner for å komme til artistens side på sosiale medier Tilgang til å spille av video C-bruker må kunne spille av 1 video fra nettsiden Tabell 1: Funksjonelle krav med prioritet 1. 10

11 5.3.2 Tabell 2, funksjonelle krav med prioritet 2 og 3 Beskrivelse Akseptansekrav Prioritet Validering av input Alle former for input som utføres 2 av bruker på nettsiden, bør ha en veiledning og/eller valideres Redigere nyhetsartikkel B-bruker bør kunne redigere 2 nyhetsartikkel Prioritere nyhetsartikkel B-bruker bør kunne prioritere 2 nyhetsartikkel etter dens ønskede/ valgte prioritet Legge til/redigere B-bruker bør kunne legge til/ 2 videodetaljer redigere videodetaljer (informasjon om video) Legge til/redigere B-bruker bør kunne legge til/ 2 bildedetaljer redigere bildedetaljer (informasjon om bildet, bildetittel) Abonnere på nyhetsbrev C-bruker bør kunne melde seg opp 3 på nyhetsbrev Meldes av nyhetsbrev C-bruker bør kunne melde seg av 3 nyhetsbrev Tabell 2: Funksjonelle krav med prioritet 2 og 3. 11

12 6. Ikke-funksjonelle krav Kort om hva ikke-funksjonelle krav er. Brukervennlighet, leveransekrav og krav til standarder. 6.1 Brukervennlighet Brukervennlighet er et punkt/krav som er meget sentralt og viktig i denne kravspesifikasjonen. Det er særdeles viktig for oppdragsgiveren at det skal være enkelt for nettsidens brukere å navigere seg frem til ønsket mål. Nettsiden skal være intuitiv for nye brukere, samt oppfylle brukerens forventninger til nettsiden. Det er også viktig å tilrettelegge for at brukeren vil besøke nettsiden regelmessig, men dette faller naturligvis også på oppdragsgiveren da de selv må regelmessig oppdatere nyheter, bilder, videoer o.l. på nettsiden. Dette punktet er også meget sentralt og viktig i forhold til CMS, ettersom oppdragsgiveren spesifikt har fortalt at det skal være enkelt å kunne administrere nettsiden for alle i firmaet. På bakgrunn av dette ser vi at det er viktig at vi forstår hvem sluttbrukerne vil bli, både når det kommer til CMS og nettsiden. Vi må vite hvilke oppgaver de skal kunne utføre og hvordan de ønsker å utføre disse. Med andre ord, vi ønsker at designet, strukturen og systemet skal være utformet med tanke på de to ulike brukergruppene (heretter omtalt som CMS-brukere og nettsidebrukere). 6.2 Leveransekrav Vi skal bruke materiale på nettsiden som blir gitt av oppdragsgiveren. Under materiale mener vi til bilder, biografi og informasjon om artisten. Designet må være godkjent før levering av produktet. De funksjonelle og ikke-funksjonelle kravene med prioritet 1 skal være innfridd. I tillegg til dette skal også kravspesifikasjonen være fulgt slik at vi forsikrer oss om at avtalen mellom oppdragsgiver og gruppen blir overholdt. Ved produktleveranse må alt av tilganger og materiale bli overlevert til oppdragsgiveren. Herunder mener vi tilgangen til databaser og administrator i CMS, samt alle filer som er brukt i nettsiden og CMS. 12

13 6.3 Krav til standarder Vi følger dagens standarder og metodikken vi har lært på HiOA. Vi benytter oss av følgende verktøy: HTML5, CSS3, JavaScript, PHP og MySQL. PHP vil bli brukt for å utvikle front-end og back-end for nettsiden. 6.4 Tabell med oversikt over ikke-funksjonelle krav Beskrivelse Akseptansekrav Prioritet Nettsiden skal lett Det skal være lett og eksponere 1 eksponeres nettsiden, slik at den lett kan brukes på oppdragsgiverens andre artister God brukervennlighet Det skal ikke ta mer enn 2 minutter 1 på nettsiden og i CMS for førstegangsbrukeren å finne det den søker Intuitiv nettside og CMS Det skal være oversiktlig og 1 selvforklarende hvilke muligheter brukeren har på nettsiden Vedlikehold nettside/cms Funksjonene skal være 2 dokumentert, slik at det kan gjennomføres vedlikehold av nettsiden Håndtere mange samtidige Nettsiden/systemet bør tåle flere 2 brukere hundre samtidige besøkende brukere Responstid for innlasting Reponstiden bør være under 3 2 sekunder for innlasting av selve nettsiden Responstid for spørringer Responstiden bør være under 3 2 sekunder for samtlige spørringer på nettsiden Responstid i CMS Responstiden i CMS bør ikke 2 overstige 3 sekunder (med unntak av opplastning av filer, da dette er forskjellig basert på filstørrelse) Alle skal kunne bruke Nettsiden bør være tilrettelagt 2 nettsiden alle uavhenig av funksjonsnivå og eventuelle funksjonsnedsettelser Alle skal enkelt kunne CMS skal være lett å lære seg for 2 lære seg CMS A- og B-brukere, slik at de raskt kan benytte seg av det 13

14 7. Logisk datamodell (E/R modell) Figur 5-2: logisk datamodell. 14

15 8. Eksterne krav Under dette punktet vil vi vektlegge krav som bygger mye på universell utforming, og lovmessige krav. 8.1 Estetiske krav I forhold til estetiske krav er det viktig å bygge på krav i forhold til universell utforming, altså at alle skal kunne bruke denne nettsiden. Dette vil ikke gjelde CMS like mye, ettersom oppdragsgiveren har forklart at det er de ansatte som skal benytte seg av dette. Det er vanskelig å tilrettelegge for alle på en god måte, dette på grunn av at spennet er stort i menneskers funksjonsevne og funksjonsnedsettelser. Derfor er det slik at når et produkt skal designes, bør en ta høyde for dette. Med andre ord bør produktet være så fleksibelt som mulig, uten at dette går på bekostning av noe annet. Dette gjelder tilpasning for brukere og de eventuelle brukssituasjonene. Krav som bør oppfylles er følgende: Nettsiden bør kunne gi informasjon til også de som har synsnedsettelser eller personer som er blinde. Dette kan ofte gjøres ved hjelp av et verktøy mange har på datamaskinen sin, at den kan lese opp tekst som står på nettsiden. Vi har derfor brukt alt-attributter på bilder, ikoner og symboler, slik at informasjonen kan bli lest opp. Nettsiden må kunne benyttes av personer som er fargeblinde. Vi har derfor tatt hensyn til dette med tanke på fargevalg og fargekombinasjoner. Vi har begrenset oss til sort, hvitt, i tillegg til dette har vi oransje, som er en farge som vanligvis ikke er vanskelig for fargeblinde å se i følge kilde nr. 8. Vi mener fargene varierer tydelig i intensitet med gode kontraster. Nettsiden må kunne benyttes av personer som har nedsatt/redusert hørsel eller personer som er døve. I denne sammenheng er ikke dette like essensielt som personer som har synsnedsettelser, ettersom personer som mangler eller har nedsatt/redusert hørsel, kan lese og betjene nettsiden godt uten noe særlig mer tilrettelegging. Den eneste begrensningen vil være mangel på lyd/musikk i videoene. 15

16 Nettsiden må kunne betjenes av personer med redusert/manglende fingerferdighet, men dette er verktøy som den enkelte ofte innehar selv. Nettsiden må kunne brukes av personer med ulik kognitiv forståelse. Dette har vi tilrettelagt ved at det er enkelt å navigere seg rundt på siden, samt at det blir gitt informasjon og tilbakemeldinger til brukeren hva som skjer hvis de trykker på en knapp. Strukturen er satt opp veldig oversiktlig og greit, nettopp fordi den skal treffe det eventuelle store spennet av brukere. Nettsidens besøkere vil primært være nordmenn, men i tillegg vil engelsk være tilgjengelig som alternativ. Nettsiden må være effektiv, med dette mener vi at det ikke skal ta for lang tid å laste inn nettsiden og heller ikke fra brukeren trykker på noe og til nettsiden responderer. 8.2 Lovmessige krav Vi har tatt hensyn til flere lovmessige krav, loven om opphavsrett, designretten, personvernloven og diskriminerings- og tilgjengelighetsloven. Grunnen til at vi har tatt spesielt hensyn til disse er fordi de står meget sentralt i forhold til utvikling av en nettside og CMS-verktøy. Lovene angår design, implementering og produksjon av nettside og CMS. Vi ønsker å understreke at ved overlevering av prosjektet til oppdragsgiver, blir det videre selvsagt deres ansvar da vi fraskriver oss alle rettigheter til nettsiden og CMS ved prosjekts slutt Opphavsrett Fra prosjektets oppstart har avtalen alltid vært at opphavsretten og eneretten tilhører Tetriz Event & Management. Dette styres av åndsverksloven, referanse nr Åndsverkloven sier i 1. følgende: «Den som skaper et åndsverk, har opphavsrett til verket. Med åndsverk forståes i denne lov litterære, vitenskapelige eller kunstneriske verk av enhver art og uansett uttrykksmåte og uttrykksform» Med andre ord vil dette i all realitet si at vi satt med opphavsretten når vi startet prosjektet, men samtidig har vi skrevet en avtale om at alt av materiale og tilgang vil bli gitt til oppdragsgiveren ved prosjektets ende, samt at 16

17 vi skal slette vårt materiale og våre tilganger, herunder gjelder selvsagt brukernavn og passord. Ved å henvise til referanse nr. 5-5, 7 kan vi forklare hvorfor vi har logoen til oppdragsgiveren nederst på nettsiden, den forteller følgende: «Som opphavsmann ansees, når ikke annet godtgjøres, den hvis navn eller alment kjente dekknavn eller merke på sedvanlig måte er påført eksemplar av verket eller blir oppgitt når det gjøres tilgjengelig for almenheten. Er et verk utgitt uten at opphavsmann er navngitt i samsvar med første ledd, kan utgiveren eller, hvis heller ikke han er navngitt, forleggeren handle på opphavsmannens vegne inntil denne blir navngitt på en ny utgave eller ved melding til vedkommende departement.» Designretten Det er en lov som beskytter retten til designet, designretten. Innunder denne retten beskrives det at andre som ønsker å benytte seg av designet, må ha en tillatelse fra designhaveren, dette gjelder ofte en avtale om produksjon og salg. Designretten er også oppdragsgiveren sin Personvernloven Dette er en lov som omhandler hvordan persondata skal behandles. Vi henviser til referanse nr. 5-7, 1. Lovens formål: «Formålet med denne loven er å beskytte den enkelte mot at personvernet blir krenket gjennom behandling av personopplysninger. Loven skal bidra til at personopplysninger blir behandlet i samsvar med grunnleggende personvernhensyn, herunder behovet for personlig integritet, privatlivets fred og tilstrekkelig kvalitet på personopplysninger.» Denne loven angår spesielt «nyhetsbrevet» ettersom vil bli lagret, brukeren kan velge om den vil lagre telefonnummer. I loven forstås det at det gjelder opplysninger som kan knyttes til en enkeltperson, dette gjelder også ved registreringer, personopplysninger som vil bli lagret i databaser slik at den enkelte kan finnes igjen. Ved å referere til punkt 7 17

18 i loven, «samtykke: en frivillig, uttrykkelig og informert erklæring fra den registrerte om at han eller hun godtar behandling av opplysninger om seg selv.» Vi har derfor understreket dette under «Kontakt» og muligheten for å melde seg opp til nyhetsbrev Diskriminerings- og tilgjengelighetsloven Denne loven skal fremme likestilling og likeverd. Det blir vektlagt at loven forbyr diskriminering på grunn av nedsatt funksjonsevne. Loven vektlegger både direkte/indirekte diskriminering, vi henviser til referanse nr. 5-8, 6. som sier følgende: «Trakassering på grunn av nedsatt funksjonsevne er forbudt. Med trakassering menes handlinger, unnlatelser eller ytringer som virker eller har til formål å virke krenkende, skremmende, fiendtlig, nedverdigende eller ydmykende.» Det er en paragraf som gjelder spesifikt for universell utforming, vi henviser til 9 i referanse nr «Med universell utforming menes utforming eller tilrettelegging av hovedløsningen i de fysiske forholdene, herunder, informasjons- og kommunikasjonsteknologi (IKT), slik at virksomhetens alminnelige funksjon skal benyttes av flest mulig.» Med dette ser vi at også vi plikter oss å sikre universell utforming så langt dette ikke vil medføre en uforholdsmessig byrde for virksomheten. Ved å lese loven ser vi at fra og med 1. juli 2011 ble det lovbestemt at alle nye teknologier og systemer skal være universelt utformet i henhold til lovverket. Vi mener selv vi virkelig har prøvd å forholde oss til denne loven, spesielt med tanke på design og utførelse av spørringer på nettsiden. Dette er også noe oppdragsgiveren bør opprettholde, samt jobbe videre med. 18

19 9. Endringshåndtering Under punktet redegjør vi for ulike endringer som vi var nødt til å foreta oss, hvorfor vi måtte det og hvordan vi valgte å løse dette. 9.1 Krav ved forslag til endringer Sidestrukturen har vært endret, men det har ikke vært de store forandringene som ble gjort her. Tidligere, se vedlegg nr. 5-1, var det satt opp at «Nyhetsbrev» skulle ha sin egen underside, og at «Booking» skulle være en underside av «Kontakt», men disse har vi fjernet da vi mente at dette var lite hensiktsmessig. Vi refererer til figur 1 i kravspesifikasjonen for å se den nye sidestrukturen. Den logiske datamodellen (E/R modellen), henviser til vedlegg nr. 5-2, måtte oppdateres en gang underveis. De største endringene som ble gjort er i forhold til «Bilde-tabellene». Dette ble gjort for at den skulle være uavhengig av hvilken mappe bildene ble lagret i. Slik at CMS kan bestemme om disse skal vises på forsiden eller undersider, eller ikke vises i det hele tatt. Det ble endret hvordan kontaktinformasjon lagres, slik at den som har ansvaret for å oppdatere kontaktinformasjonen selv kan forme layout. Vi la til en e-post adresse som booking forespørsler, slik at den senere kan oppdateres. En annen endring som ble gjort er i forhold til «Nyhetsbrev», ettersom vi ikke har funksjonaliteten til å sende nyhetsbrev, derfor har vi heller ikke muligheten til å slette nyhetsbrev. Vi fjernet muligheten til å melde seg av nyhetsbrev, refererer til neste avsnitt under punkt 9.1. Funksjonaliteten er stort sett den samme som tidligere versjon, se figur 5-2 i kravspesifikasjonen. Vi har vært nødt til å foreta en endring i forhold til funksjonelle krav, henviser til tabellen under punkt Tabell 2, funksjonelle krav med prioritet 2 og 3 i kravspesifikasjonen. Kravet vi ønsker å forandre er «Meldes av nyhetsbrev», vi har ikke klart å opprette noen innbygget funksjon til å sende nyhetsbrev og vi har derfor heller ikke noen innebygget funksjon for mottakere å melde seg av igjen dette. Det er derfor Tetriz sitt ansvar å sende nyhetsbrev og vil derfor også selv ha ansvaret for å fjerne mottakere som ønsker å bli meldt av. En annen ting som har blitt endret underveis er fremdriftsplanen, naturlig nok. Grunnen til at vi sier at dette er naturlig er fordi det alltid er vanskelig å beregne hvor 19

20 lang tid noe skal ta, før det faktisk har blitt gjort. En kan støte på problemer som er «tyngre» og dermed vanskeligere å fikse. 9.2 Feilhåndtering Vi har støtt på en feil i forhold til bilder, dette med tanke på hvordan bilder lastes opp og hvorvidt disse kan brukes som miniatyrbilder i galleriet. Løsningen ble å regne ut hvor mye RAM den kan laste opp og tillate miniatyrbilder. Dette vil bli forklart nærmere i Testdokumentasjonen, punkt 2.2 «Test grafisk grensesnitt». En annen feil som vi ikke har klart å rette opp er i forhold til skjermmodus. Problemet er at et element ikke viser seg slik det egentlig burde ha blitt vist i «minmeringsskjerm», men det vises riktig i fullskjermmodus. Vi henviser til vedlegg nr. 5-3, der det vises hvordan dette ser ut i «minimeringsskjerm», og henviser til vedlegg nr. 5-4, der det vises hvordan dette ser ut i fullskjermmodus. Dette er slik vi ønsket at det skulle se ut i «minimeringsskjerm» også. I bunn og grunn er det ikke noe galt med dette, men vi skulle ønske vi hadde kompetansen og tiden til å fikse dette, da det ikke ser like pent ut. Navigasjonsbaren går delvis over bildet i slideshowet. 20

21 10. Referanseliste Nr.5-1: Nr.5-2: Nr.5-3: Nr.5-5: Opphavsrett: Nr.5-6: Designretten: Nr.5-4: /6.html?id= Nr.5-7: Personvernloven: Nr.5-8: Diskriminerings- og tilgjengelighetsloven: Nr.5-9: Nr.5-10: Tilgjengelighet på WEB: Nr.5-11: Web Accessibility Initiative (WAI): Nr.5-12: 21

22 11. Vedlegg Vedlegg nr.5-1, Sidestruktur: 22

23 Vedlegg nr.5-2, Logisk datamodell. 23

24 Vedlegg nr.5-3, skjermdump av «minimeringsskjerm». 24

25 Vedlegg nr.5-4, fullskjermmodus. 25