KRAVSPESIFIKASJON FORORD Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer og krav til funksjonalitet og design. Utviklingsprosessen foregår smidig ved bruk av utviklingsverktøyet Trello (beskrevet i prosessdokumentasjonen). Å jobbe på denne måten vil si å levere produktet fortløpende i delleveranser slik at deler av funksjonaliteten blir implementert og kan bli godkjent av kunden. en er basert på de krav som ble stilt både ved prosjektstart og under utviklingsfasens iterasjoner. Kravene til prosjektgruppen ble gitt både som individuelle funksjonaliteter og referanser til eksisterende applikasjoner. Implementasjon av denne funksjonaliteten blir diskutert i prosess- og produktrapportene. Kravene ble delt i to forskjellige kategorier - minimumskrav og ønsket ekstrafunksjonalitet. Minimumskravene ble ansett som førsteprioritet, mens ønsket ekstrafunksjonalitet ble sett på som mulige arbeidsoppgaver om tiden tillot. en har fungert som et styringsdokument for gruppen, og har endret seg fortløpende ut fra erfaringer og kunnskap utviklet underveis i prosjektet. Samtidig oppdaterte vi kravspesifikasjonen når vi mottok nye ønsker fra oppdragsgiver. Side 1 av 8
INNHOLD Forord... 1 Innledning... 3 Bakgrunn for oppgaven... 3 Systemkrav... 3 Kundens krav til funksjonalitet... 3 Ønsket tilleggsfunksjonalitet... 4 Tekniske krav... 4 Krav til koden... 4 Sikkerhetskrav... 4 Krav til grensesnitt... 5 Generelle designkrav... 5 Bruk av farger og fonter - merkevarebygging... 5 Dokumentasjonskrav... 5 Konklusjon... 6 Side 2 av 8
INNLEDNING Prosjektet gjennomføres som et hovedprosjekt ved Høgskolen i Oslo og Akershus (HiOA) avdeling for ingeniørutdanning for Bekk Consulting AS og deres kunde Get AS. Det skal produseres en applikasjon for Digipost for Android-baserte smarttelefoner. Applikasjonen skal ha samme funksjonalitet som dagens versjon på ios, og være designet i tråd med Google sine retningslinjer for Android-utvikling. Bekk skal utvikle denne applikasjonen for Digipost (heretter referert til som kunden) og vi vil utvikle applikasjonen for Bekk (heretter referert til som oppdragsgiver). Innledningsvis bestod kravspesifikasjonen av kundens krav til funksjonalitet, som innebærer at applikasjonen skulle ha samme funksjonalitet som den eksisterende applikasjonen for ios. Videre funksjonelle krav har blitt lagt til underveis i utviklingsprosessen. En konsekvens av dette har vært at vi ikke har hatt en kravspesifikasjon som et ferdig styringsdokument fra starten. Krav til design og kode har blitt satt i samarbeid med oppdragsgiver og kunden. BAKGRUNN FOR OPPGAVEN Som orientert om i presentasjonen er formålet med Digipost er å erstatte den eksisterende løsningen for utsendelse av konfidensiell post med sikker elektronisk post. Hver konto er basert på postadresse. Her kan lønnsslipper, kvitteringer og annen personlig eller konfidensiell post sendes på en trygg måte. Digipost tilbyr også stor lagringsplass i et personlig arkiv der brukeren kan lagre post, dokumenter og annet. For Androidbrukere var eksisterende løsning kun en nettside tilpasset mobile enheter med hensyn på skjermstørrelse. Det eksisterer en native Digipost versjon for ios som et eksternt firma, Shortcut AS, har utviklet på oppdrag fra kunden. Dette ble lansert i 2011 og har vært under kontinuerlig utvikling siden. Kunden ønsker seg nå en applikasjon for mobile enheter som benytter Android operativsystem. SYSTEMKRAV KUNDENS KRAV TIL FUNKSJONALITET Kundens grunnleggende krav er å implementere all funksjon dagens ios-applikasjon tilbyr. Følgende krav som satt av kunden beskriver grunnleggende funksjonalitet til applikasjonen og applikasjonen skal tilby: pålogging med OAuth2 og sikker lagring av refresh token ny access token basert på refresh token skal skje automatisk uten at bruker merker det tvinge innføring av skjermlås med passord eller fingerbevegelse for å sikre innhold ved tyveri av telefonen utlogging liste ut metadata o liste ut brev i postkassen o liste ut brev på kjøkkenbenken o liste ut innhold i arkivet o liste ut elektroniske kvitteringer vise innhold knyttet til metadata o vise pdf o vise html Side 3 av 8
flytte brev fra postkasse til arkiv flytte brev fra postkasse til kjøkkenbenk flytte brev fra kjøkkenbenk til arkiv og visa versa ØNSKET TILLEGGSFUNKSJONALITET Følgende krav er tilleggsfunksjoner som gjennom utviklingsprosessen ble ønsket av oppdragsgiver, disse funksjonene er ikke nødvendigvis implementert i kundens eksisterende mobilapplikasjoner, men ønskes utforsket og eventuelt implementert: sikker lagring av brev opplastning til arkiv offline-funksjonalitet/ hendelseskø push-notifications TEKNISKE KRAV applikasjonen skal utvikles i Java, XML og C applikasjonen skal kunne kjøres på Androidenheter med operativsystemversjon 4.0 eller høyere applikasjonen skal fungere på alle Android telefoner, Android nettbrett og Android PCer som oppfyller versjonskravenene funksjonalitet på bekostning av kjente sikkerhetshull eller mangler skal ikke implementeres data skal lagres kryptert brukeren skal vente kortest mulig på at innhold lastes ned nettverksspørringer skal utføres i egne programtråder nettverksbruken skal minimeres ved nedlastning av store filer skal det være mulig å avbryte underveis KRAV TIL KODEN Vi ble enige om at all kode og alle kommentarer skal skrives på engelsk, og føre en konsekvent linje på det. Ellers skal koden være mest mulig oversiktlig, og gjøre det enklest mulig for kunden å overta, vedlikeholde og videreuvikle applikasjonen. Utviklingsmønsteret MVC skal benyttes for å strukturere koden Navn på klasser, metoder og variabler skal være såpass forklarende at det ikke er nødvendig med kommentarer Koden skal implementeres og struktureres slik at den enkelt kan utvides med ny funksjonalitet SIKKERHETSKRAV Følgende sikkerhetskrav stiller Digipost til applikasjoner som skal benytte deres API. Trafikken skal krypteres all trafikk som inneholder tokens eller Digipost-data skal krypteres, f.eks. ved å bruke HTTPS Side 4 av 8
Refresh_tokens skal lagres kryptert disse har samme verdi som passord, og kan f.eks. lagres i keychain eller krypteres med en sterk kryptering (f.eks. AES256). Dersom man krypterer med egne krypteringsnøkler, skal disse lagres adskilt fra refresh_tokens (ikke holde begge to i samme database). Det skal benyttes forskjellig krypteringsnøkkel i utviklingsmiljø og produksjon. De skal ikke benyttes som parametere i URL-er eller lignende Access tokens skal ikke lagres i klartekst disse skal ha samme verdi som en sesjons-id. Disse kan normalt sett bare holdes i minnet pga. kort varighet på tokenet, men skal man lagre dem på disk, bør de lagres på tilsvarende måte som refresh tokens. Access tokens skal ikke benyttes som parametere i URL-er eller lignende Client secret skal lagres kryptert Se krav for refresh token. Dette gjelder ikke for mobilapplikasjoner e.l. State skal brukes og sjekkes state-parameteren skal gis en unik kryptografisk tilfeldig verdi, og denne skal senere sjekkes Ved bruk av Digipost for innlogging, skal id token verifiseres - signatur og client id skal verifiseres. Ugyldige tokens skal forkastes KRAV TIL GRENSESNITT GENERELLE DESIGNKRAV Applikasjonen skal føles som en fullverdig Android applikasjon Navigasjonen skal føles enkelt og intuitivt Grafiske elementer skal ha et flatt og moderne utseende Bruker skal sitte igjen med inntrykk av et ferdig produkt Ikoner skal se bra ut sammen med andre applikasjoner på Hjem-skjermen Bruker skal få varslinger som står i stil med varslingsgrunnlaget Det skal være enkelt å endre designelementer i ettertid BRUK AV FARGER OG FONTER - MERKEVAREBYGGING Det skal brukes farger fra webutgaven Det skal brukes standard Android font (Roboto Regular) DOKUMENTASJONSKRAV Eneste kravet til dokumentasjonen fra oppdragsgiver og kunde var at innholdet ikke skulle være i strid med de taushetserklæringer og andre avtaler vi har skrevet under på i forbindelse med prosjektet. Side 5 av 8
KONKLUSJON en har spilt en sentral rolle for oss da vi konkretiserte prosjektets rammer og omfang. Prosjektets rammer var definert på en måte som gjorde at utviklingen av selve applikasjonens funksjonalitet var fleksibel og tilpasningsdyktig. Ved å ha et krav om at applikasjonen skulle ha samme funksjonalitet som kundens øvrige mobilapplikasjoner, men mulighet for ny funksjonalitet gjennom nye iterasjoner, hadde vi et godt fundament for hva som skulle jobbes med, samtidig som kunden var sikret et brukbart produkt ved prosjektslutt. Det ferdige produktet tilfredsstiller alle krav fra kunden, både med tanke på funksjonalitet, design og kode. Ekstrafunksjonaliteten ble funnet for tidkrevende å implementere, men med de utfordringene vi har hatt rundt den øvrige funksjonaliteten har kunden likevel ytret at vår innsats har oversteget deres forventninger. Basert på dette og tilbakemeldinger fra oppdragsgiver og kunden, legger vi til grunn at vårt produkt samsvarer med kravspesifikasjonen og overgikk forventningene fra oppdragsgiver og kunden. Oppfyllelse av krav er i mer detaljert form beskrevet i produktrapporten. Side 6 av 8
< Denne siden skal være blank > Side 7 av 8
< Denne siden skal være blank > Side 8 av 8