2014 Vedlegg A Høgskolen i Oslo og Akershus [KRAVSPESIFIKASJON] Jonas Moltzau & Martin W. Løkkeberg Gruppe 12
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
1. Introduksjon Hovedprosjekt 2014 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 API 1 med tilhørende web-grensesnitt 2, 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 2
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 notasjon slik. 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. 3
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 matvaretabell 3, og et API med tilhørende web-grensesnitt utviklet i MS Visual Studio 4, 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, retter 5 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 administrasjonsside 2. Denne skal administrator kunne bruke til å hente ut rådata for videre statistisk bearbeidelse. Rådata skal suppleres i et brukervennlig format slik som XML 6. 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 enhet 7 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 referanseinntak 8 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. 4
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 prinsippet 9. 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 filformat 6. 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 hashet 10 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. 5
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 versjonen 11 av Android 4.4 (KitKat; API nivå 19) c) Applikasjonen skal utvikles i Java 12 og XML med Eclipse IDE 13 med Android SDK 14. d) Applikasjonen skal lages etter MVC 15 mønsteret i tråd med standarden for Android. e) APIet skal utvikles i Microsoft sitt.net rammeverk 16. f) APIet skal kodes i C# 17. g) APIet skal være RESTful 18. h) APIet skal utvikles i Microsoft Visual Studio 2012 etter MVC mønsteret med entity framework 19. 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. 6
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. 7
4. Ordliste 1 API 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. 2 web-grensesnitt/ administrasjonsside Her menes: En nettside som henter data fra APIet og presenter dette for bruker. 3 Matvaretabell Mattilsynets matvaretabell som ligger til grunn for matvaredatabasen. Kan finnes her: http://www.matvaretabellen.no. 4 MS Visual Studio Visual Studio er et integrert utviklingsmiljø (IDE) for Microsofts.NET plattform. 5 Retter Her menes: En rett er et objekt som består av to eller flere ingredienser hentet fra matvaretabellen med et fast mengdeforhold. 6 XML XML (Extensible Markup Language) er et universelt og utvidbart markeringsspråk (språk som kombinerer tekst og ekstra informasjon om teksten). 7 Naturlig 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) 8 Referanseinntak Her menes: Standard referanseinntak for vitaminer og mineraler samt energibehov (se Harris-Benedikt prinsippet). 9 Harris Benedict prinsippet Er en metode for beregning av en persons basalmetabolisme (hvilestoffskiftet). 10 Hashet 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. 11 Android versjon Google anbefaler å rette utviklingen mot nyeste versjon av Android (se http://developer.android.com/guide/practices/compatibility.html for detaljer). 12 Java Java er et multiplattform objektorientert programmeringsspråk. 13 Eclipse IDE Eclipse er et flerspråklig utviklingsmiljø (IDE) med støtte for utvidet funksjonalitet ved programvareutvidelser (slik som Android SDK). 14 Android SDK Et utviklingsbibliotek for androidplattformen. 15 MVC Model View Controller er en måte å dele opp og strukturere koden på i en applikasjon. 16 Microsoft.NET.NET eller.net Framework er en samling teknologier rundt programvareutvikling fra Microsoft. 17 C# C# er et programmeringsspråk for objekt-orientert programmering, utviklet av Microsoft, som en del av deres satsing på.net. 18 REST Representational State Transfer, er en programvarearkitektur for distribuerte systemer som World Wide Web. REST har etter hvert blitt den dominerende designmodellen for web-apier. 19 Entity Framework Er et object-relational mapping (ORM en konverteringsteknikk for objekter til database) rammeverk. En del av.net. 8