2014

Høgskolen i Oslo og Akershus

[KRAVSPESIFIKASJON] Jonas Moltzau & Martin W. Løkkeberg Gruppe 12

Vedlegg A

Innhold

Innhold .................................................................................................................................................... 0

1. Introduksjon ........................................................................................................................................ 2

1.1 Presentasjon .................................................................................................................................. 2

1.2 Forord ............................................................................................................................................ 3

1.3 Leserveiledning .............................................................................................................................. 3

1.4 Bakgrunn ....................................................................................................................................... 3

2. Systembeskrivelse ............................................................................................................................... 4

2.0.1 Mål for systemet .................................................................................................................... 4

2.1 Funksjonelle krav ........................................................................................................................... 4

2.1.1 Applikasjon [1]: ....................................................................................................................... 4

2.1.2 Kost API og administrasjonsside[2]: ....................................................................................... 5

2.2 Ikke-funksjonelle krav .................................................................................................................... 6

2.2.1 Brukervennlighet: ................................................................................................................... 6

2.2.2 Effektivitetskrav: ..................................................................................................................... 6

2.2.3 Sikkerhetskrav ........................................................................................................................ 6

2.2.4 Implementasjonskrav: ............................................................................................................ 6

2.2.5 Leveransekrav: ........................................................................................................................ 6

2.2.6 Fremtidig utvidelse av systemet ............................................................................................. 7

2.2.7 Lovmessige krav ..................................................................................................................... 7

2.2.8 Krav til grensesnitt .................................................................................................................. 7

4. Ordliste ................................................................................................................................................ 8

Vedlegg A

2 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

1. Introduksjon

Hovedprosjekt 2014 Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

1.1 Presentasjon

Tittel: Kost Oppgave: Å utvikle en IT-løsning for innrapportering av data for bruk i forskning, bestående av en Android applikasjon og et API1 med tilhørende web-grensesnitt2, for registrering av matkonsum og uthenting av statistiske rådata. Gruppenummer: 12 Gruppemedlemmer: Jonas Moltzau Martin W. Løkkeberg Veileder: Eva Hadler Vihovde Oppdragsgiver: Studieretning for samfunnsernæring Institutt for helse ernæring og ledelse Fakultet for helsefag Høgskolen i Oslo og Akershus Ansvarlig for oppgaven (HIOA): Asgeir Brevik 483 53 097 Email: Asgeir.Brevik@hioa.no

Vedlegg A

3 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

1.2 Forord

Kravspesifikasjonen er et internt styringsdokument beregnet som en avtale mellom oppdragsgiver og oppdragstager. Det skal i dette dokumentet fremlegges hvilke krav oppdragsgiver har til systemet for at det skal kunne utføre de oppgaver oppdragsgiver vil effektivisere. Kravspesifikasjonen er beregnet på alle interessenter i prosjektet, og er skrevet deretter mtp. faguttrykk og liknende.

1.3 Leserveiledning

Kravspesifikasjonen er delt inn i Forord, Leserveiledning, Bakgrunn, Systembeskrivelse, Funksjonelle krav, Ikke-funksjonelle krav og konklusjon.

Forordet beskriver kravspesifikasjonens rolle generelt i prosjektet. Bakgrunn beskriver aktualiteten til prosjektet. Systembeskrivelse er en tekstlig beskrivelse av systemet og dets funksjonalitet, samt rollen det

spiller for oppdragsgiver.

Funksjonelle krav er delt inn i krav for hver del systemet, disse er merket med notasjonen [n]. Del [1] er applikasjonen for Android, mens del [2] er APIet og administrasjonssiden. Under hver av disse delene merkes hvert krav med notasjonen a) - z), når det henvises til et spesifikt krav, gjøres dette på formen [2a] for del 2 krav a). Ord og uttrykk som kan være uklare eller trenger forklaring er samlet i en ordliste på slutten av dokumentet. Ord som har en forklaring er merket med en superskript notasjonslik.

1.4 Bakgrunn

HIOA Institutt for helse, ernæring og ledelse (HEL) holder til på studiested Kjeller. For å ha høy kvalitet på undervisningen fokuserer undervisningspersonalet på å holde seg oppdatert innenfor forskning og fagutvikling. Oppgaven er forespurt av studieleder ved Samfunnsernæring Asgeir Brevik.

Vedlegg A

4 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

2. Systembeskrivelse

Oppgaven går ut på å utvikle en IT-løsning for innrapportering av data for bruk i forskning ved Instituttet HEL. Denne skal bestå av en Android applikasjon, hvor brukere kan registrere kostholdsvaner basert på mattilsynets matvaretabell3, og et API med tilhørende web-grensesnitt utviklet i MS Visual Studio4, for registrering av matkonsum og uthenting av statistiske rådata. Systemet skal forenkle forskningsprosessen for forskere i ernæringsmiljøet ved HEL, samt at den skal appellere til vanlige brukere og promotere kostholdsbevissthet. Android applikasjonene skal gi brukeren muligheten til å registrere sine kostholdsvaner i form av matvarer tatt fra matvaretabellen, retter5 som er komponert enten av brukeren selv eller prekomponert av studenter ved HEL. Det skal også kunnes registrere måltider som kan bestå av både retter og matvarer, disse skal bare komponeres av brukeren og lagres på brukerens telefon. Funksjonalitet for å organisere matvarer, retter og måltider skal implementeres på en måte som gjør systemet lett forståelig og brukervennlig. Brukeren skal ha muligheten til å enkelt kunne søke etter valgt matvare, rett eller måltid og deretter kunne legge dette til som spist for denne dagen. Når matvaren, retten eller måltidet er registrert skal brukeren kunne følge sitt næringsinntak på hjemskjermen ved enkle figurer, og deretter kunne gå mer i detalj via tabeller og liknende. Applikasjonen skal sende denne dataen til APIet daglig, der det lagres anonymisert. APIet skal tilby matvaretabellen i et programmeringsvennlig rammeverk. Man skal kunne hente ut ønsket informasjon om matvarer, retter og evt. ernæringsvaner etter administrators diskresjon. Administrator vil få tilgang til å sette inn informasjon og gi tilganger via en administrasjonsside2. Denne skal administrator kunne bruke til å hente ut rådata for videre statistisk bearbeidelse. Rådata skal suppleres i et brukervennlig format slik som XML6.

2.0.1 Mål for systemet

- Bidra til enklere informasjonsinnsamling av ernæringsdata. - Å skape lettere tilgang til matvaretabellen. - Hjelpe brukere med å få oversikt over eget kosthold.

2.1 Funksjonelle krav

2.1.1 Applikasjon [1]:

2.1.1.1 Minimumskrav:

a) Mulighet til å registrere konsum av enkle matvarer og drikke fra matvaretabellen

b) Mulighet for bruker å lokalt komponere enkle måltider ut ifra råvarer fra matvaretabellen.

c) Volum/mengdeangivelse for matvarer i naturlig enhet7 og/eller i gram.

d) Visning av enkel grafikk, f.eks. kakediagram, som indikerer det prosentvise bidraget av henholdsvis karbohydrat, protein og fett, evt. andre relevante næringsstoffer, til det totale energiinntaket.

e) Mulighet til å vise logget/registrert inntak av ulike næringsstoffer i en tabell eller liste til brukeren, med referanseinntak8 markert som tallverdi eller nivå.

f) Applikasjonen skal rapportere samlet dagsinntak av matvarer til ekstern database én gang i døgnet så fremt den har internettilgang.

g) Mulighet for bruker å registrere anonym konto med brukernavn, passord, høyde (f), vekt (f), alder, aktivitetsnivå (f)og kjønn.

Vedlegg A

5 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

h) Applikasjonen skal ha en lokal kopi av databasen over matvarer og retter.

i) Applikasjonen skal ha en navigeringsmeny som alltid er tilgjengelig.

j) Bruker skal kunne søke, og bla gjennom, matvarer, retter og måltider.

k) Energibehovet skal beregnes ut ifra Harris–Benedict prinsippet9.

l) Applikasjonens lokale database skal kunne sømløst oppdateres til nyeste versjon av APIets database for retter og matvarer.

2.1.1.2 Ønsket tilleggsfunksjonalitet:

m) Engelsk versjon av applikasjonen.

n) Utvide funksjonaliteten i krav [1e] til å vise statistikk over inntak av spesifikke næringsstoffer i løpet av siste uke, mnd., år osv.

o) Utvide krav [1f] med rapportering av måltider, måltidstidspunkt, type måltid osv.

2.1.1.3 Eventuell tilleggsfunksjonalitet:

p) Mulighet til å legge ved bilde til brukernes selvlagde retter og måltider.

2.1.2 Kost API og administrasjonsside[2]:

2.1.2.1 Minimumskrav:

a) Mulighet for registrering av retter i databasen via et web-grensesnitt for administrasjon av APIet heretter referert til som administrasjonssiden.

b) Eksportere statistisk rådata fra et spesifisert tidsrom til administrasjonssiden i form av tabeller eller relevant filformat6.

c) APIet skal ha flere ulike databaser dette inkluderer databaser for; matvarer fra matvaretabellen, retter opprettet av oppdragsgiver, brukerinformasjon, og rapporterte data fra brukere.

d) Innrapportering av data i henhold til registrering av næringsstoffer skal lagres med knytning til brukernavn.

e) Brukernavn og passord skal lagres hashet10 for sikkerhet og anonymitet.

f) Det skal kunne hentes ut matvarer og retter enkeltvis eller som datasett fra APIet med riktig autorisasjon.

2.1.2.2 Ønsket tilleggsfunksjonalitet

g) Brukerinnsendt data skal kunne kontrolleres av APIet og data som vekker mistanke vil forkastes automatisk eller kreve manuell godkjenning. (f. eks. et kaloriinntak på 20 000).

2.1.2.3 Eventuell tilleggsfunksjonalitet:

h) Mulighet til å legge ved bilde i krav [2a].

i) APIet skal kunne logge endringer som er gjort i databasen.

j) Mulighet for administrator å kunne legge inn nye brukere til administrasjonssiden med et valgt adgangsnivå.

k) Krav [2i] utvides til å kunne bruke denne loggen for å gjenopprette tidligere tilstand.

Vedlegg A

6 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

2.2 Ikke-funksjonelle krav

Under hele utviklingen skal det fokuseres på å utvikle en fungerende løsning som ved lansering kan brukes av oppdragsgiver. Dette vil si at tertiærfunksjonalitet vil kunne forsakes for å oppnå dette.

2.2.1 Brukervennlighet:

a) Applikasjonen skal være fullt fungerende uten internettilgang.

b) Applikasjonen skal være på norsk.

c) Applikasjonen skal være intuitiv.

d) Applikasjonen skal gi bruker muligheten til å konfigurere så mange innstillinger som mulig for å kunne skreddersy sin brukeropplevelse.

e) Applikasjonen skal fungere “out of the box” uten konfigurasjon for de fleste brukere.

2.2.2 Effektivitetskrav:

a) Så nært som mulig 100% av alle tunge beregninger skal foregå på server, hvis dette er mulig for den gitte oppgaven.

b) Applikasjonen skal føles som en naturlig del av telefonen og være så rask som situasjonen tillater.

2.2.3 Sikkerhetskrav

a) Det skal være mulig å sikkerhetskopiere all data på databasen.

b) All data som lagres om brukere skal lagres anonymisert og det skal ikke være mulig å knytte denne dataen til en person uten samtykke, og hjelp, fra bruker.

c) APIet skal alltid autentisere brukere av informasjonen lagret i databasen og skal følge normale sikkerhetsstandarder.

2.2.4 Implementasjonskrav:

a) Applikasjonen skal ha minimumsversjon 4.0.3 (Ice Cream Sandwich; API nivå 15)

b) Applikasjonen skal rettes mot den nyeste versjonen11 av Android 4.4 (KitKat; API nivå 19)

c) Applikasjonen skal utvikles i Java12 og XML med Eclipse IDE13 med Android SDK14.

d) Applikasjonen skal lages etter MVC15 mønsteret i tråd med standarden for Android.

e) APIet skal utvikles i Microsoft sitt .net rammeverk16.

f) APIet skal kodes i C#17.

g) APIet skal være RESTful18.

h) APIet skal utvikles i Microsoft Visual Studio 2012 etter MVC mønsteret med entity framework19.

2.2.5 Leveransekrav:

a) Den ferdige applikasjonen skal være klar for lansering i Android Play Store.

b) Det ferdige APIet skal leveres ferdig installert på en Windows server.

c) Windows serveren skal leies av oppdragsgiver og vedkomne skal stå ansvarlig på alle måter i forhold til denne.

d) Det skal ikke foregå vedlikehold eller drift fra oppdragstagers side etter at produktet er levert, med mindre dette avtales spesifikt.

Vedlegg A

7 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

2.2.6 Fremtidig utvidelse av systemet

a) Koden for systemet skal så langt det er mulig håndtere et ubegrenset antall brukere, begrensninger skal evt. ligge i oppdragsgivers valg av serverløsning.

b) Koden skal i aller største grad tilrettelegge for videreutvikling for større funksjonalitet

2.2.7 Lovmessige krav

a) Applikasjonen skal inneholde teksten: "Inneholder data under norsk lisens for offentlige data

(NLOD) tilgjengeliggjort av Matvaretilsynet."

b) Applikasjonen skal opplyse om, og avskrive seg ansvar for, eventuelle feil og mangler som måtte forekomme.

2.2.8 Krav til grensesnitt

a) Applikasjonens utseende skal ligge nært det normale utseende for Android applikasjoner.

b) Det skal være kort vei til de mest brukte funksjonene og det skal, så langt det er mulig, gå an å nå disse innenfor 3 «klikk».

c) Applikasjonen skal benytte seg av et enkelt menysystem som følger brukeren under hele brukerforløpet.

Vedlegg A

8 Hovedprosjekt 2014 - Kost Fakultet for teknologi og design, Høgskolen i Oslo og Akershus

4. Ordliste

1API Her menes: Serversideprogramvare som håndterer forespørsler fra internett, verifiserer identitet, autoriserer databaseaksess, henter ut data fra databasen og sender dette tilbake.

Generelt: Application Programming Interface (API) er et grensesnitt for kommunikasjon mellom programvare. APIet beskriver de metoder som en gitt programvare eller et bibliotek kan kommunisere med.

2web-grensesnitt/ administrasjonsside Her menes: En nettside som henter data fra APIet og presenter dette

for bruker. 3Matvaretabell Mattilsynets matvaretabell som ligger til grunn for

matvaredatabasen. Kan finnes her: http://www.matvaretabellen.no. 4MS Visual Studio Visual Studio er et integrert utviklingsmiljø (IDE) for Microsofts .NET

plattform. 5Retter Her menes: En rett er et objekt som består av to eller flere

ingredienser hentet fra matvaretabellen med et fast mengdeforhold. 6XML XML (Extensible Markup Language) er et universelt og utvidbart

markeringsspråk (språk som kombinerer tekst og ekstra informasjon

om teksten). 7Naturlig enhet Her menes: Den enhet som er mest nærliggende nå man snakker om

en spesifikk matvare. (f. eks. ett glass melk, ett stk. eple, en skive ost) 8Referanseinntak Her menes: Standard referanseinntak for vitaminer og mineraler

samt energibehov (se Harris-Benedikt prinsippet). 9Harris–Benedict prinsippet Er en metode for beregning av en persons basalmetabolisme

(hvilestoffskiftet). 10Hashet En sjekksum, en kort kode som brukes til å sjekke integriteten av

dataofte kalt hash-funksjon. Ikke reversibel, original data kan ikke

hentes ut fra sjekksummen. 11Android versjon Google anbefaler å rette utviklingen mot nyeste versjon av Android

(se http://developer.android.com/guide/practices/compatibility.html for detaljer).

12Java Java er et multiplattform objektorientert programmeringsspråk. 13Eclipse IDE Eclipse er et flerspråklig utviklingsmiljø (IDE) med støtte for utvidet

funksjonalitet ved programvareutvidelser (slik som Android SDK). 14Android SDK Et utviklingsbibliotek for androidplattformen. 15MVC Model View Controller er en måte å dele opp og strukturere koden

på i en applikasjon. 16Microsoft .NET .NET eller .NET Framework er en samling teknologier rundt

programvareutvikling fra Microsoft. 17C# C# er et programmeringsspråk for objekt-orientert programmering,

utviklet av Microsoft, som en del av deres satsing på .NET. 18REST Representational State Transfer, er en programvarearkitektur for

distribuerte systemer som World Wide Web. REST har etter hvert blitt den dominerende designmodellen for web-APIer.

19Entity Framework Er et object-relational mapping (ORM – en konverteringsteknikk for objekter til database) rammeverk. En del av .NET.

Vedlegg A