Kravspesifikasjon. Kristian Johannessen, Michael Andre Krog, Lena Sandvik, Alexander Welin, Snorre Olimstad Gruppe

Transkript

1 2012 Kravspesifikasjon Kristian Johannessen, Michael Andre Krog, Lena Sandvik, Alexander Welin, Snorre Olimstad Gruppe

2 1. Forord Kravspesifikasjonen beskriver oppdragsgiver, bakgrunnen for prosjektet og prosjektplass i oppdragsgivers fremtidsplaner. Den skal gi en oversikt over fremgangsmåten som skal brukes ved utredning av rammeverk for kryssutvikling. Videre skal den gi oss og oppdragsgiver en forståelse av systemet og funksjonaliteten til mobilapplikasjonen som senere skal utvikles. Enkelte krav er laget i forhold til krav som stilles av Høgskolen i Oslo og Akershus. Dette fremgår da av kravformuleringer. 2. Leserveiledning Kravspesifikasjonen er, i likhet med oppgaven, delt opp i to deler. Den er optimalisert for å leses på web og papir. Dokumentet er skrevet med en del fagrelaterte ord og utrykk med tanke på at oppdragsgiver er kjent med programmering og utvikling av store prosjekter. Derfor vil noen utrykk bli skrevet på engelsk i og med at det er mer relatert til programmeringsverdenen (som source control og input). For ordforklaring, se vedlegg. For at kravspesifikasjonen skal hjelpe oss mest mulig underveis har vi delt den opp i flere hovedpunkter og delpunkter som er sortert etter arbeidsplanen og innleveringene til gruppen. Kravene til utredningen av prosjektet er spesifisert i del 1, mens kravene til utvikling er spesifisert i del 2.

3 3. Innhold 1. Forord Leserveiledning Presentasjon Bakgrunn Overordnet systembeskrivelse Kravspesifikasjon Utredningsfase Prosesskrav: Beslutningsgrunnlag: Kravspesifikasjon for testapplikasjon: Funksjonelle krav: Ikke-funksjonelle krav: Oppdragsgivers krav til dokumentasjonen: Kravspesifikasjon Utviklingsfasen Funksjonelle krav: Ikke-funksjonelle krav: Brukervennlighet og design: Testkrav: Tekniske krav: Dokumentasjonskrav: Mulige utvidelser: Use Case Oversikt Detaljering Logg inn Registrere seg Søke (tekst/glideskala) Søke på kart Levere söknad Laste opp CV Kildehenvisning... 22

4 4. Presentasjon Tittel: Kryssplattformutvikling for mobile enheter Oppgave: Finne verktøy for kryssplattformutvikling, og lage en komplett applikasjon for WebCruiter Gruppemedlemmer: Kristian Johannessen Lena Marie Sandvik Alexander Wehlin Michael Andre Krog Snorre Helmert Olimstad Prosjektgruppe: Gruppe 15 Veileder: Eva Hadler Vihovde Oppdragsgiver: WebCruiter AS Kontaktperson: Lars Erik Johannessen Tlf:

5 5. Bakgrunn WebCruiter er et norsk firma med ca 25 ansatte. Selskapet har utviklet og levert webbaserte rekrutteringsløsninger siden De har kunder innenfor de fleste bransjer og benyttes i dag av mer enn brukere i mer enn 40 land. De er opptatt av å sikre kundene sine raske, driftssikre og fremtidsrettede løsninger, og benytter markedets ledende utviklingsverktøy og databaseteknologi. WebCruiter har et mål om å etablere seg på det mobile markedet. For å oppnå dette jobber de med en løsning for publisering på web som skal skaleres til mobile plattformer. Selskapet har per i dag ingen erfaring med utvikling av mobilapplikasjoner. Selskapet ønsker hjelp til å finne et godt rammeverk for kryssplattformutvikling. Vi skal utvikle en jobbagent-applikasjon med det valgte verktøyet. Plattformene de sikter seg inn mot er de tre antatt største: Android, ios og Windows Overordnet systembeskrivelse Dette kapitlet beskriver applikasjonen som skal lages i utviklingsfasen. Applikasjonen er en jobbagent som skal gi mulighet for å søke etter stillinger og vise disse. I tillegg skal man kunne lage en profil, laste opp CV og levere søknader på stillinger. En uregistrert bruker skal kunne søke etter stillinger på kart, utføre søk med fritekst/glideskala og ha mulighet for å vise detaljer for en valgt stilling. En registrert (innlogget) bruker har derimot flere privilegier i tillegg til de ovennevnte. Det er først etter å ha registrert seg og logget seg inn at brukeren har tilgang til endring av persondata, utmelding og selvfølgelig utlogging. Da kan man også laste opp CV til applikasjonen og levere en søknad på en valgt stilling om du allerede er innlogget.

6 7. Kravspesifikasjon Utredningsfase 7.1. Prosesskrav: 1) Det skal først lages en oversikt over de mest aktuelle utviklingsrammeverkene. Et rammeverk er aktuelt når det: a. Støtter Android, ios og Windows Phone 7.5. b. Har tilgang til den enkelte plattforms API. c. Er et rammeverk for å lage native applikasjoner. d. Har støtte for opp mot 100 % felles kode. e. Ikke er en beta-release. f. Er lett tilgjengelig. 2) Det skal lages en analyse av fordeler og ulemper for hvert aktuelt rammeverk. 3) Det skal også lages en rangering basert på et poenggivningssystem. 4) Deretter skal det velges ut tre rammeverk blant disse for mer detaljert utredning. 5) Det skal være samsvar med de tre utvalgte rammeverkene og de som topper rangeringen. 6) Rammeverkene skal utredes suksessivt. Det skal med andre ord kun jobbes med ett rammeverk om gangen. 7) De valgte rammeverkene skal installeres det skal altså ikke brukes webbaserte IDE er. a. Presisering: Installasjon skjer som første steg i utredning av et nytt rammeverk; altså som ledd i den suksessive utredningsprosessen. 8) Det skal lages en testapplikasjon per rammeverk (se egen kravspesifikasjon for denne). 9) Rammeverkene skal sammenlignes. 10) Fordeler, ulemper og poenggivning skal revurderes. a. Ytterligere punkter kan legges til Beslutningsgrunnlag: 1) Det skal fattes beslutning ut fra følgende hovedpunkter: a. Tilgjengelighet b. Modenhet c. Utviklingsprosess d. Teknologi 2) De ovennevnte punktene skal reflekteres i poengberegningen.

7 3) Tilgjengelighet skal vurderes ut fra: a. Anskaffelse i. Er det lett å laste ned og installere? b. Integrering med utviklingsmiljøer: i. Hvilke utviklingsmiljøer som støttes. ii. Det foretrekkes at disse er veletablerte. c. Support: i. Oppbygning av hjemmeside; lett tilgjengelig relevant informasjon. ii. Direkte kundestøtte i form av telefon eller e-post. iii. Tutorials og videoseminarer. iv. Hvorvidt leverandøren har egne forumer, wiki-sider eller lignende. d. Community: i. I hvor stor grad produktet omtales på forumer på andre domener. e. Lisensiering: i. Hvilke kostnader som påløper ved kjøp av lisens eller publisering av applikasjoner. ii. Hva som inkluderes i lisensen i form av support, oppfølgning med mer. iii. Presisering: Hvis lisensieringsmodellen innebærer svært varierende kostnader, teller dette negativt. 4) Modenhet skal vurderes ut fra: a. Versjoner: i. Hvor utviklet verktøyet er. ii. Hvor ofte nye versjoner kommer ut, samt hvor godt disse er dokumentert. b. Utbredelse: i. Størrelse på selskapet bak, samt samarbeidspartnere. ii. Markedsandeler; herunder hvor stor brukerbase rammeverket har. c. Erfaring: i. Hvor lenge rammeverket har vært på markedet. ii. Markedsandeler; herunder erfaring med kundebehandling. d. Omtale: i. Referanser fra andre selskaper og enkeltutviklere. e. API-støtte: i. Skal vurderes som et eget punkt. ii. Omfang og likhet mellom plattformer. f. Krysskompatibilitet: i. Skal vurderes som et eget punkt. ii. Mest mulig felles kode. iii. Støtter de aktuelle plattformene. 5) Teknologi skal vurderes ut fra: a. Utbredelse av programmeringsspråk. b. Fleksibilitet. c. Kompleksitet.

8 6) Følgende punkter skal legges til vurderingen etter utredningsprosessen: a. Stabilitet under modenhet. Stabilitet skal vurderes som et eget punkt og omfatter: i. Kjøring av programmer skjer uten problemer. ii. Ytelsesevner som responstid, kompatibilitet etc. b. Utviklingsprosess skal vurderes ut fra: i. Enkelhet rundt oppretting av prosjekt. ii. IntelliSense. iii. Source Control. iv. Debugging. v. Integrasjon med tredjeparts moduler/biblioteker Kravspesifikasjon for testapplikasjon: Funksjonelle krav: 1) Det skal kunne hentes data fra WebCruiters database og vise på skjerm. 2) Applikasjonen skal vise en posisjon i et kart Ikke-funksjonelle krav: Brukervennlighet og design 1) Skjermbildet skal kunne vises både liggende og stående. 2) Applikasjonen skal presentere data på en ryddig og oversiktlig måte. 3) Flest mulig UI-elementer skal testes ut, herunder: a. Knapper b. Tabeller/grids c. Tekstbokser d. Labels e. Bilder 4) Samme data skal kunne vises flere ganger i de forskjellige ovennevnte UIelementene. Dette for å teste flest mulige elementer.

9 Tekniske krav: 1) Programmering skal gjøres på engelsk. 2) Koden skal være ryddig og strukturert. 3) Filene skal ha logiske navn og ordnes i logiske pakker. 4) Der koden ikke er selvforklarende skal det kommenteres, og ellers der det er hensiktsmessig. Kommentarer skal skrives rett over den relaterte koden Eventuelle utvidelser: 1) Ytterligere funksjonalitet kan legges til hvis de ovennevnte krav ikke gir et tilfredsstillende bilde av rammeverket Oppdragsgivers krav til dokumentasjonen: 1) Begrunnelse for valg av de tre verktøyene skal legges frem for WebCruiter. 2) Eventuelle avvik fra denne kravspesifikasjonen skal dokumenteres. 3) Konklusjonen skal inneholde anbefaling av ett verktøy til WebCruiter.

10 8. Kravspesifikasjon Utviklingsfasen WebCruiters database er meget kompleks og inneholder mye sensitiv informasjon. De vil derfor ikke eksponere denne direkte til oss. Videre finnes ikke data for Geolocation i deres database per dags dato. Det vil derfor settes opp en dummy-database til vårt bruk. Denne vil inneholde all data vi har behov for. Når det i dette kapitlet refereres til WebCruiters database, menes denne dummy-databasen Funksjonelle krav: 1) Det skal kunne opprettes og oppdatere brukere i databasen. a. Brukere skal registreres med fullt navn, fødselsdato, telefonnummer, adresse, passord og e-postadresse. i. E-postadresse brukes som brukernavn. 2) Det skal kunne søkes i databasen. a. Det skal kunne søkes etter stillinger etter følgende kriterier: i. Fag/bransje. ii. Nåværende posisjon. 3) Søk skal kunne benytte seg av glideskalaer (Figur 1). Figur 1: Glideskala fra OneCall 4) Det skal implementeres en kartfunksjon som benytter telefonens Location Services til følgende: a. Vise nåværende posisjon. b. Finne stillinger innen en gitt radius fra posisjonen (bruke glideskala). 5) Stillinger fra kart skal kunne presenteres på skjermen. 6) All input skal valideres slik at det sikres mot SQL-injections med mer.

11 7) Visse elementer av applikasjonen skal kreve innlogging. Dette omfatter: a. Endring av brukerdata. b. Slette konto. 8) Administrasjon av applikasjonen skjer fra WebCruiter og er ikke en del av oppgaven Ikke-funksjonelle krav: Brukervennlighet og design: 1) Applikasjonen skal være på norsk. 2) Det skal vektlegges at dette er en mobilapplikasjon. Det innebærer: a. Skjermbildet skal kunne vises både liggende og stående. b. Det skal ikke være mange elementer per side. c. Ingen elementer skal dekke mer enn hele skjermbildet. d. Elementer skal være tilpasset touch-navigering. 3) Fargespekteret skal gjenspeile WebCruiter. 4) Det skal brukes farger med tydelige kontraster som egner seg på skjerm. 5) Skjermbildene skal ha en logisk oppbygning som er enkel å forstå Testkrav: 1) Applikasjonen skal testes på utviklingstelefonene som er utdelt fra oppdragsgiver. 2) Der det er hensiktmessig skal programfeil utbedres underveis Tekniske krav: 1) Applikasjonen skal utvikles i verktøyet som ble valgt i del 1. 2) Det skal brukes source control, om det er fysisk mulig. 3) Applikasjonen skal ikke kommunisere direkte med WebCruiters database. Kommunikasjon skal skje via et service-lag på server-siden. 4) Programmering skal gjøres på engelsk. 5) UI-kontroller, metoder og variabler skal ha logiske navn, som passer inn i kontekst. a. Eksempel: Knapp for søk skal hete btnsearch. 6) Koden skal være ryddig og strukturert. 7) Filene skal ha logiske navn og ordnes i logiske pakker. 8) Der koden ikke er selvforklarende skal det kommenteres, og ellers der det er hensiktsmessig. Kommentarer skal skrives rett over den relaterte koden.

12 8.3. Dokumentasjonskrav: 1) Rapporten(e) skal følge dokumentasjonsstandarden til HiOA. 2) Eventuelle avvik fra denne kravspesifikasjonen skal dokumenteres. 3) Hvis opplevelsen av verktøyet har endret seg i løpet av utviklingen skal vi melde fra til WebCruiter. 4) Styringsdokumenter skal oppdateres jevnlig. 5) Sluttdokumentasjonen skal omfatte følgende deler: a. Presentasjon av oppgaven. b. Produktdokumentasjon for utredning og utvikling. c. Prosess dokumentasjon for utredning og utvikling. i. Utredning og utvikling er selvstendige elementer. d. Kravspesifikasjon. e. Brukerveiledning. 6) Rapporten fra utredningsfasen skal legges ved sluttdokumentasjonen Mulige utvidelser: 1) Få opp flere/færre stillinger dynamisk ved endring av radius. 2) Søke på stillinger i kart fra annen posisjon enn nåværende. 3) Sortering på resultater av søk i databasen (relevans, dato, osv). 4) Lagring av søk/legge til i en liste med favoritter. 5) Interaktiv brukerveiledning. 6) Man kan få passordet tilbakestilt (hvis brukeren glemmer det). Tilbakestilt passord sendes til E-postadressen. 7) Brukere kan laste opp bilde. 8) Søk etter: a. Firma. b. Fritekst. c. Søknadsfrist. d. Kvalifikasjoner. 9) Lagre søk. a. Stillinger b. Søkekriterie. For eksempel alle stillinger som dataingeniør kan hentes fram igjen, og nye stillinger som er lagt inn etter forrige søk hentes frem.

13 10) Levere jobbsøknad. 11) Laste opp CV.

14 9. Use Case 9.1. Oversikt Under er en overordnet oversikt over alle Use Case (Figur 2). Disse er strukturert i Tabell 1. Videre har vi valgt å detaljere de viktigste Use Case med beskrivelser av hovedflyt og alternativ flyt (avsnitt 9.2). Use Case som er markert med rødaktig farge er mulige utvidelser. Figur 2: Use Case Diagram

15 Use Case Beskrivelse 1 Logg inn Brukeren logger seg inn. 2 Logg ut Brukeren logger seg ut. 3 Registrere seg Brukeren registrerer seg for å få full tilgang. 4 Nullstille passord Brukeren har glemt passord, får tilsendt nytt på e-post. 5 Utmelding Brukeren melder seg ut av tjenesten. 6 Endre data Brukeren redigerer persondata. 7 Søke (tekst/glideskala) Brukeren søker etter stillinger med tekst eller bruk av glideskala. 8 Lagre søk Brukeren lagrer søk for bruk med nettapplikasjon. 9 Søke på kart Brukeren søker etter stillinger ut fra nåværende posisjon. 10 Vise stilling Brukeren velger å se detaljert informasjon om stilling. 11 Levere søknad Brukeren leverer søknad på en stilling. 12 Laste opp CV Brukeren laster opp CV knyttet til sin profil. Tabell 1: Oversikt over Use Case. De som er uthevet er detaljert

16 9.2. Detaljering Logg inn Hovedaktør: Bruker. Interessenter: Applikasjon og bruker. Prebetingelser: Må ha internett tilgang. Må være registrert i applikasjonen. Postbetingelser: Bruker er innlogget. Hovedflyt (suksess) 1) Bruker åpner applikasjonen 2) Bruker navigerer seg til innloggingsvinduet. 3) Bruker skriver inn brukernavn og passord. 4) Sjekk på uutfylte felter. 5) Utfylte felter valideres opp mot registrert bruker i database. 6) Bruker er innlogget og blir navigert til hovedsiden av applikasjonen. Extension points: Logg ut Utmelding Endre data Laste opp CV Alternativ flyt (feiltilfeller) 3a. Bruker har glemt passord. Løsning: Bruker kan velge å tilbakestille passord og få tilsendt nytt på e-post (UC-4). 4a. Bruker har glemt å fylle inn nødvendige felt. Løsning: Bruker blir bedt om å fylle ut nødvendige felter. 5a. Innloggingsdata er feil. Innlogging feiler. Løsning: Bruker må begynne om igjen med utfylling av felter.

17 Registrere seg Hovedaktør: Bruker. Interessenter: Applikasjon og bruker. Prebetingelser: Bruker må ha en privat e-postadresse. Postbetingelser: Bruker logges inn og startmenyen vises. Hovedflyt (suksess) 1) System ber om nødvendige data for å registrere. 2) Bruker fyller inn informasjonen systemet ber om, og trykker på knappen bekreft. 3) Systemet registrerer brukeren. Alternativ flyt (feiltilfeller) 1a. Bruker har ikke fylt ut alle obligatoriske felter. Løsning: Systemet gir beskjed om dette og brukeren må gjenta prosessen fra punkt 2. 2a. Bruker avbryter registreringen. Løsning: Applikasjonen navigerer deg tilbake til hovedmenyen og ingen informasjon lagrer seg.

18 Søke (tekst/glideskala) Hovedaktør: Bruker. Interessenter: Applikasjon og bruker. Prebetingelser: Ingen Postbetingelser: Resultatet av søket vises. Extension points Vise stilling Lagre søk Hovedflyt (suksess) 1) Bruker skriver inn nøkkelord i søkefelt eller søker ved bruk av glideskala eller en kombinasjon. 2) Bruker trykker på knappen søk. 3) Applikasjonen søker etter stillinger. 4) Applikasjonen presenterer resultatet til brukeren. Alternativ flyt (feiltilfeller) 1a. Søkefeltet er tomt og glideskala er ikke stilt inn. Løsning: Applikasjonen gir beskjed om dette. 2b. Ingen treff på søket. Løsning: Applikasjonen gir beskjed om dette.

19 Lagre søk Hovedaktør: Bruker. Interessenter: Applikation och bruker. Prebetingelser: Måste vara registrerad. Har tillkoppling till internet. Vara inloggad. Har gjort ett sök. Postbetingelser: Lagrer sök till profilen. Hovedflyt(Suksess): 1) Användaren trycker på knappen lagre sök. 2) Applikationen vill ladda upp söket till databasen. 3) Söknaden blir nu lagrad till profilen och tillgänglig från hanns profil på telefonen och på internet. 4) Navigeras till profilen. Alternativ flyt (feiltilfeller) 2a. Applikationen kan inte hitta databasen. Lösning: Felmeddelande om att koppling till databasen inte kunde hittas.

20 Søke på kart Hovedaktør: Bruker. Interessenter: Applikasjonen og bruker. Prebetingelser: Telefonen har tilgang til internett. Posisjon er slått på. Postbetingelser: Stillinger innen en gitt radius vises på kartet. Eller Ingen stillinger fantes innen radiusen brukeren har fått beskjed om dette. Extension points Vise stilling Hovedflyt (suksess) 1. Brukeren navigerer til side for kartsøk. 2. Applikasjonen viser kart og glideskala for valg av radius. 3. Brukeren velger en radius. 4. Applikasjonen laster kart med nødvendig zoomnivå for å vise valgte radius. 5. Applikasjonen plasserer markeringer på stillinger. Alternativ flyt (feiltilfeller) 2a. Feil ved lasting av kart. Løsning: Applikasjonen presenterer en feilmelding med beskjed til brukeren om å prøve igjen senere. 5a. Ingen stillinger ble funnet innen radiusen. Løsning: Applikasjonen gir brukeren beskjed om enten å gå tilbake til steg 3 og velge en større radius eller å prøve igjen senere.

21 Levere söknad Hovedaktør: Bruker. Interessenter: Applikation og bruker. Prebetingelser: Måste vara registrerad och inloggad. Ha tillkoppling till internet. Postbetingelser: Söknad skickad till ett företag. Hovedflyt (suksess) 1. Navigerar till önskad jobbansökan. 2. Användaren klickar på knappen lever söknad. 3. Applikationen visar att ansökan har blivit skickad och sänder tillbaka användaren till jobbansökans startsida. Alternativ flyt (feiltilfeller) 2a. Användaren har inte laddat upp en CV till sin profil. Lösning: Användaren vill bli förfrågad om att ladda upp en CV (JA/NEI). Lösning2. JA: Användaren blir skickad till (UC-11). Lösning3: NEI: Användaren blir skickad till jobb ansökan.

22 Laste opp CV Hovedaktør: Bruker. Interessenter: Applikation og bruker. Prebetingelser: Måste vara registrerad och inloggad. Ha tillkoppling till internet. Postbetingelser: CV uppladdad på profilen. Hovedflyt (suksess) 1. Navigerar sig till sin profil. 2. Användaren trycker på last opp CV. 3. Navigerar fram till CV filen lokalt på enheten, trycker OK. 4. Användaren trycker acceptera och laddar upp CV till server. 5. Applikationen visar profilsidan till användaren med CV som uppladdad. Alternativ flyt (feiltilfeller) 2a. Fel användarnamn/lösenord försök igen. Lösning: Användaren blir skickad till login, pröva igen. 5a. Användarens fil kan inte hittas Lösning: Användaren får ett medelande.om att inte filen existerar och blir skickad till sin profil.

23 10. Kildehenvisning 1) Onecall, sist besøkt ) Agile Modeling, sist besøkt ) NTNU, sist besøkt