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å å 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?
- Funksjonelle krav 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 |
Av brukerhistoriene, så ble 1, 2 og 3 implementert. Brukerhistorie 1 var obligatorisk, og et must ettersom det var det grunnleggende vi måtte ha for at spillet faktisk skal være et spill. Dette var den mest tidkrevende funksjonaliteten i prosjektet, noe som gir mening med tanke på at det var hele grunnlaget for spillet. Brukerhistorie 2 var også et must have, ellers oppnår aldri spilleren progresjon i spillet på grunn av at de får ikke sett om de har fanget alle Pokémonene. Gotta catch them all er slagordet for Pokémon, og det hadde tatt seg ille ut å ikke kunne fange alle sammen. Et brukergrensesnitt er nemlig en svært viktig del å inkludere i et spill, og kan betydelig forbedre spillopplevelsen. Brukerhistorie 3 var et could have, og passet godt i kombinasjon med brukerhistorie 2, så ble dermed også implementert.
Brukerhistorie 4 ble ikke implementert grunnet mangel på selve "pokèballen" som vi forsøkte å få 3D printet for prosjektet. Med denne ballen så kunne vi enkelt montert en lysdiode på ballen, og skrevet kode som fikk den til å lyse opp når en Pokémon ble bekreftet fanget. Med mangel på et fysisk grensesnitt (pokèballen) så var det lite motiv for oss å legge til denne funksjonaliteten.
Brukerhistorie 5 var en avansert oppgave, og ble ikke gjennomført på grunn av at det var svært tidkrevende. Utfordringene her hadde vært å designe og bygge applikasjonsarkitekturen, grensesnittet og kommunikasjonen mellom spillere om vi skal ha flerspillerfunksjonalitet (Ref brukerhistorie 7).
Brukerhistorie 6 ble ikke gjennomført grunnet mangel på GPS modul på Arduinoen. Vi fikk ikke tak i et selvstendig GPS modul som vi kunne lodde til Arduinoen, og den Arduinoen som eksisterte med akselerometer og GPS modul var ikke lengre til salgs. Vi var borti et spesielt Arduino bibliotek som lot oss få GPS koordinater til Arduinoen basert på trådløse nettverk i nærheten ved bruk av Google Maps GeoLocation API. Dette viste seg å være lite nyttig for oss grunnet manglende presisjon og mangel på å ha et pålitelig antall trådløse nettverk hvor enn spilleren kan befinne seg. Utfordringer med denne brukerhistorien hadde vært å kunne identifisere hva slags geografisk biome man befinner seg i ved hjelp av GPS koordinater. Vi fant ikke en åpenbar løsning på dette problemet, men det er mulig at Google Maps sin API har en løsning. Med tanke på hvordan Google Maps fargekoder terrenget sitt (Grønt for vegetasjon, blått for vann o.l) så kan det eksistere en variabel som sier hva slags biome et visst koordinat har.
Brukerhistorie 7 hvilte hovedsakelig på brukerhistorie 5 og ble heller ikke implementert. Flerspiller funksjonalitet er beryktet for å være avansert og vanskelig å utvikle. Vi hadde foretrukket å implementere bytting av Pokémon i en applikasjon, men en enklere måte å gjennomføre dette kunne vært å inkludere det i grensesnittet på nettsiden. Mangel på tid gjorde slik at vi heller ikke startet på denne brukerhistorien. Utfordringer her hadde nok vært databasearkitektur og sikkerhet. I flerspiller spill så er spillerne svært glad i å finne alle mulige måter å utnytte systemet (Mulligan, Patrovsky. 2003. s. 474), og sikkerhet hadde vært den absolutt største utfordringen over tid. (I et fiktivt scenario der vi faktisk har spillere og ett lansert produkt)
Brukerhistorie 8 ble ikke implementert på grunn av mangel på tid. Funksjonaliteten den tilbød var ikke stor, så vi valgte å ikke bruke tid på den. Den hadde ikke tilbudt på noen utfordringer, ettersom det hadde bare vært en ekstra random "roll".
Brukerhistorie 9 var klassifisert som won't, og var ikke veldig relevant for prosjektet (annet enn den tekniske utfordringen). Utfordringer her hadde vært å lage ett sikkert og pålitelig system for å håndtere pengetransaksjoner. Ikke implementert.
Brukerhistorie 10 var også klassifisert som won't. Og i likhet med brukerhistorie 9 så var den for det meste bare for teoriens skyld. Også ikke implementert.
Ikke-funksjonelle krav går ut på hvordan vi skal implementere de funksjonelle kravene. Mer spesifikk 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 |