Analyse og design
Analyse og design tar for seg hvilke funksjoner som er nødvendig og er behov for i løsningen. For å kartlegge funksjonaliteten man ser for seg har vi brukt brukerhistorier for å utføre dette. Det er to hovedmåter å gjøre dette på:
- Som en X, vil jeg at Y, slik at Z.
- For å unngå Z, som en X, ønsker jeg Y.
Det vil her komme frem viktigste rute og funksjonalitet for de historier man ser av størst relevans. Et annet verktøy vi har brukt er rike bilder. Rike bilder tegner opp et helhetlig bilde av hvordan bruker interagerer med system og produkt. Andre viktige metoder og verktøy som vi har brukt er liste over funksjonalitet og MoSCoW for å prioritere; Must have, Should have, Could have og Won’t have. Design er den delen som beskriver utseende for vår Nettløsning.
Rikt bilde er en teknikk for analyse og kartlegging av problematiske situasjoner som danner et bilde av hvordan systemet vi lager bygges opp. På denne måten ser vi hvem som er mest sentralt og hvilken syn de har på situasjonen, og vi kan komme til en bedre forståelse av hva vi vil oppnå med det nye systemet. Vi har valgt å lage to rike bilder av essensielle funksjoner i systemet, det hvor den ene fokuserer på det helhetlige bildet av hele systemet og det andre tar for seg en av de viktigste brukerhistoriene. I våres rike bilder har vi ingen formell syntaks, men vi har valgt å bruke noen symboler som for eksempel strekmennesker og piler som representerer relasjonen mellom elementene. Vi valgte å tegne bildene for hånd ettersom det føltes best.
Bildet under viser hvordan hele konseptet med pokeballen fungerer. Spilleren kaster pokeballen på en Pokémon. For at kastet skal blir gjenkjent så sender Arduinoen data til databasen. Når dataen er gjenkjent så er det om å vente på å finne ut om den var et godkjent kast eller ikke. Hvis den blir godkjent så benytter Arduinoen data hentet fra API'et, "kalkulere" resultatet fra API'et og sende viss data (Pokémon ID) til databasen.
Det rike bildet under viser når en spiller vil finne ut hvordan man kan få sett hva slags Pokémon man har fanget.
For å vise hvordan brukeren vil interagere med ulike lag i implementasjonen har vi valgt å bruke brukerscenarioer. Brukerscenarioer er historien om hvordan våres målgrupper opptrer. Altså visuelle tankeøvelser som viser hvordan brukeren vil samhandle med alle elementene i implementeringen. Før vi begynte å lage bruker scenarioene satte vi oss en realistisk mål for brukeren som tar i bruk Arduinoen. Videre prøvde finne ut hvordan vår persona oppfører seg og vite hva vår persona har tilgang til.
Sett fra brukerens perspektiv, hvordan brukeren forholder seg til Arduino og resultater på web applikasjonen.
Sett fra systemets perspektiv, hvordan de forskjellige komponentene samarbeider.
Sett fra brukerens perspektiv så bruker brukeren webapplikasjon til å se på resultatet.
Sett fra systemets perspektiv, ved hjelp av wifi på arduinoen så kan man få sendt data til databasen for så og oppdatere webapplikasjonen.
Etter å ha analysert de rike bildene og design av bruker scenarioene, laget vi brukerhistorier for å utvide forståelsen av det vi har laget. Som sagt så har vi brukt MoSCoW’s analysemetodikk til å gjøre det. MoScoW brukes til å fordele krav vi har innad brukerhistoriene til fire kategorier for å se på verdien på hver av kravene og rangere disse. I Moscow's metodikk rangerer brukerhistoriene etter Must have, Should have, Could have og Won’t have. Brukerhistorier som er “Must have” må bli implementert i systemet for at det skal bli brukt. “Should have” blir tolket som brukerhistorier som bør implementeres, men som ikke er nødvendig å ha. “Could have” er brukerhistorier som kan bli implementert dersom vi har tid. “Won’t have” er brukerhistorier vi ikke vil ha med enten fordi det er for omfattende eller ikke har noe verdi til brukeren. I tillegg til å rangere historiene med MoSCoW, har vi lagt inn en nummerert rangering etter hva vi anser til å være viktigst, til mindre viktig. Vi vil bruke dette som utgangspunkt for vår utviklingsfokus.
Hvilke tjenester (funksjoner)systemet skal tilby? Hvordan det skal reagere på ulike typer input? Vil i tillegg kunne beskrive hva systemet ikke skal gjøre.
| Nummer | Brukerhistorie | Krav | Prioritet | Implementert/Ikke implementert |
|---|---|---|---|---|
| 1 | Som en spiller, ønsker jeg å kunne fange Pokémon ved å bevege på “Pokéballen” | Aktivere generering og lagringsprosessen av Pokémon ved bruk av et akselerometer. | Must | Implementert |
| 2 | Som en spiller, ønsker jeg å ha en oversikt over hvilke Pokémon som jeg har fanget. | Implementerer en webapplikasjon som er tilgjengelig gjennom en nettleser. | Should | Implementert |
| 3 | Som en spiller ønsker jeg å kunne se hvilke potensielle Pokémon som kan bli fanget (Pokedex). | På webapplikasjonen bør det være en oversikt over alle Pokémon som eksisterer. Sortering av generasjon burde være mulig. | Should | Implementert |
| 4 | Som en spiller ønsker jeg å kunne få en form for signal/feedback når jeg har klart å fange en Pokémon. | Implementere en lysdiode, liten høyttaler eller motor som aktiveres når en Pokémon har blitt fanget. | Could | Ikke implementert |
| 5 | Som en spiller, ønsker jeg å ha en mobil applikasjon for å ha oversikt over all informasjon relevant for spillet. (Typ hva som kan fanges der jeg er, hvilke Pokémon jeg har). | Lage en app som kan vise informasjon om spillet og brukeren. | Could | Ikke implementert |
| 6 | Som en spiller, ønsker jeg å kunne fange Pokémon typer som er basert på geografisk biome. | Bruke GPS til å hente geografisk informasjon om hvor brukeren er for å bestemme hvilken Pokémontype som skal genereres. | Could | Ikke implementert |
| 7 | Som en spiller ønsker jeg å kunne bytte Pokémon med andre spillere. | Implementere en funksjon som lar brukere gi bort og bytte fangede Pokémon. | Could | Ikke implementert |
| 8 | Som en spiller, ønsker jeg å ha en mild grad av sjansespill i spillet i form av “shiny” Pokemon. | En shiny Pokemon er en unik og sjelden variant av en Pokemon med andre farger enn de “vanlige” Gjennom å ha en veldig liten sjanse for å generere en shiny Pokemon, vil spiller oppnå et dopamin rush. | Could | Ikke implementert |
| 9 | Som en spiller, ønsker jeg å betale (med ekte penger) for større sjanse å finne sjeldne og/eller shiny Pokemon. | Gjennom en betalingsplattform kan en bruker betale for lettere tilgang / større sjanse for sjeldne Pokemon. | Won’t | Ikke implementert |
| 10 | Som en spiller, ønsker jeg å betale (med ekte penger) for å lettere fange Pokemon. | Gjennom en betalingsplattform kan en bruker betale for “lettere” gameplay. | Won’t | Ikke implementert |
Ikke-funksjonelle krav går ut på hvordan vi skal implementere de funksjonelle kravene. Mer spesifikt så er det de tekniske avgjørelsene som ikke påvirker funksjonaliteten som brukeren oppfatter.
| Nummer | Krav | Prioritet |
|---|---|---|
| 8 | Bruke et rammeverk som er laget for Arduino der hvor vi har mulighet til å styre arduino på flere plattformer. | Must |
| 9 | Implementere et system for å fleksibelt endre parametre brukt i oppsettet for en Arduino. For eksempel gjennom et admin panel kan man endre hvor aksesspunktet på API’et er, istedenfor å manuelt skrive inn hostnamet til serveren API’et ligger på i selve konfigurasjonsfilen til Arduino’en. | Should |