Kravspesifikasjon Target release 1.0 Epic Document status Document owner DRAFT Martin Lyckander Designer Developers QA Forord Hensikten med en kravspesifikasjon er at den skal fungere som et styringsdokument for gruppen, slik at det blir enklere å løse uenigheter som oppstår underveis i prosjektet. Ved hjelp av kravene som er beskrevet kan man lettere ta beslutninger og justere retningen om det skulle bli nødvendig. Kravspesfikasjonen skal også fungere som en avtale mellom "oppdragsgiver". Siden det er vi som har kommet opp med ideen og skrevet oppgavebeskrivelsen vil kravspesfikasjonen gi veiledere en spesifik beskrivelse av hva vi skal lage. En av våre veileder på Accenture vil fungere som en "oppdragseier" og gi oss tilbakemeldinger da vi ikke har en spesifikk oppdragsgiver.den skal vise viktige betingelser som vi har satt oss og er for oss som skal skrive hovedprosjektet, men dokumentet er også for veiledere/ "oppdragseier".denne kan endres underveis, og vi vil kunne fjerne og legge til krav etter som prosjektet utvikles, og problemer/muligheter oppstår. Kravspesfikasjonen skal også fungere som en veileder for sensor om hva som kan forventes av dette prosjektet, slik at dette kan sammenlignes med det som kommer fram i sluttdokumentasjonen. Innledning Prosjektet skal gjennomføres som hovedprosjekt ved Høgskolen i Oslo og Akershus, ingeniøravdelingen, i samarbeid med Accenture. Oppgaven går i all hovedsak ut på å utvikle et brukerstyrt spørsmål/svar nettsted tilpasset for studenter som tar høyere utdanning i Norge. Dette skal skape en mer aktiv samhandling mellom studenter uten å måtte være avhengig av faglærer. Webapplikasjonen skal gi elever som tar samme fag mulighet til å besvare hverandres spørsmål, dele relevant informasjon, samt gi rom for diskusjon av ulike temaer. Sluttproduktet skal være et supplement til eksisterende Learning management systems som «It s learning» og «Fronter», og skal være godt tilpasset mindre mobile enheter. Bakgrunn Flere av dagens "Learning Managment Systems" (LMS) har mange gode funksjonaliteter som ofte ikke blir fullt utnyttet da det normalt er opp til hver enkelt faglærer hvor mye som skal være tilgjengelig for studentene. Dette har ført til at det har blitt vanlig å opprette private grupper på facebook hvor alt av informasjondeling som lenker og spørsmål, samt diskusjon foregår. Mange har ikke tilgang til disse lukkede facebook-gruppene og informasjonen når ofte ikke ut til alle. Det eksisterer idag en rekke ulike nettsamfunn som løser problemet med å være avhengig av faglærer. Disse nettstedene er ofte helt åpne, og all funksjonalitet er tilgjengelig for alle til enhver tid, på tvers av alle landegrenser. Utfordringen med slike nettsteder er imidlertid at de ofte har veldig store brukergrupper, og fungerer kun veldig godt for mer generell informasjonsdeling og spørsmål. Disse faktorene skaper det som er grunnlaget for vår applikasjon. Vi ønsker å skape et sted som er mer tilpasset en brukergruppe, nemlig studenter som tar høyere utdanning i Norge, uten noe form for avhengighet av faglærere. Vi vil fjerne behovet for lukkede facebook grupper, slik at det ikke blir satt samme begrensning på dagens informasjonsflyt. Tanken er at studenter skal kunne stille mer spesifikke spørsmål og få like spesifikke svar tilbake, enn hva dagens nettsamfunn tilbyr. For å frigjøre seg fra faglærere er ideen at det skal være rent brukerstyrt; studentene driver nettstedet. Vi ønsker ikke at produktet skal konkurrere med eksisterende LMS-systemer, men det skal fungere som et supplement til disse ved at det tilbyr gode alternativer der de er svakest. Den største mangelen idag er gode student-til-student interaksjoner. Overordnet systembeskrivelse
Vi har definert tre overordnet mål som beskriver selve basisen med webapplikasjonen vi skal utvikle: Utvikle en applikasjon med studenter som tar høyere utdanning i Norge som målgruppe Utvikle en applikasjon med spørsmål/svar funksjonalitet som kjernefunksjonalitet Utvikle en applikasjon som er rent brukerstyrt For å nå disse essensielle målene har vi satt opp en rekke funksjonelle og ikke-funksjonelle krav som blir beskrevet i de to tabellene nedenfor. Vi har valgt å kategorisere funksjonelle krav etter viktighet, de standardene vi har sortert etter er ",, Lav". Alle funksjonelle krav som har høy status er systemkritiske, og det er viktig at de blir fullstendig implementert. Alle funksjonelle krav som har middels status blir utviklet etter at alle funksjonelle krav med høy status er blitt implementert. Funksjonelle krav med lav status blir kun implementert skulle vi få litt tid til overs. De ikke-funksjonelle kravene er en oversikt over de kravene vi selv har satt til systemet. Funksjonelle krav # Tittel Brukerhistorie Viktighet Kommentar 1 Brukeregistering En bruker skal kunne registrere seg Bruker får spørsmål om han/hun er student eller ikke 2 Brukerinnlogging En bruker skal kunne logge inn Kombinasjon e-postadresse + passord 3 Brukerutlogging En bruker skal kunne logge seg ut fra alle steder på siden Enkel løsning 4 Nullstilling av passord En bruker skal kunne nullstille sitt glemte passord ved innlogging Random-generert passord skal sendes på e-postadresse. Bruker skal bli forespurt om å velge nytt passord ved suksessfull innlogging 5 Opprette tråder En bruker skal kunne opprette tråder Hver tråd skal ha en tittel 6 Redigere innlegg En bruker skal kunne redigere sine egne innlegg 7 Skrive innlegg i tråder En bruker skal kunne svare i opprettede tråder Innlegg har ikke tittel, men er tilknyttet en tråd 8 Rangere tråder En bruker skal kunne gi poeng til spørsmål basert på kvalitet 9 Rangere innlegg En bruker skal kunne gi poeng til innlegg basert på kvalitet 10 Tagger En bruker skal kunne tagge sine egne tråder 11 Slette innlegg En bruker skal kunne slette sine egne innlegg 12 Brukerinformasjon En bruker skal inneholde informasjon om hvem den er 13 Brukerendring En bruker skal kunne endre informasjon om seg selv Fagtilhørighet Skoletilhørighet Interesser Beskrivelse Muligheten for å endre beskrivelse, interesser og fagtilhørighet 14 Brukerregistrering som student En bruker skal kunne registrere seg med skoletilhørighet Ved brukerregistrering skal det være mulig for brukere å velge skoletilhørighet. F.eks ved skolemail. Gitt at man er registrert som student hos en skole, kan man finne studenter fra samme skole o.l. 15 Se når innlegg ble redigert En bruker skal kunne se når en tråd eller et innlegg sist ble redigert Det skal vises en lite flagg, en stjerne eller et annet symbol ved et innlegg som har blitt redigert Hva som har blitt redigert skal ikke være synlig 16 Incentivsystem Det skal eksistere en incentivsystem som skal oppfordre brukere til å aktivt bruke siden Skal baseres på poeng slik som det er gjort på Reddit og StackOverflow Viktig at dette ikke blir implementert på en måte som kan skape "poengjakt" eller skremmer folk fra å opprette innlegg
17 Søk En bruker skal kunne gjøre søk basert på tagger og trådtittel En bruker skal kunne skrive søkeord i et søkefelt 18 Sortering En bruker skal kunne sortere innlegg En bruker skal kunne sortere innlegg etter: Kvalitet Dato 19 Formatere innlegg En bruker skal kunne formatere innlegg før publisering Skal kunne endre font, skriftstørrelse osv. 20 Kommentering En bruker skal kunne kommentere innlegg Lav Antall kommentarer på et innlegg skal være synlig til enhver tid Kommentarer skal vises når en bruker f.eks trykker på en knapp 21 Opprette quiz En bruker skal kunne opprette quizer Lav Quizene skal kunne brukes som et verktøy i repetisjonssammenheng før eksamen, tester og obligatoriske oppgaver 22 Sende melding En bruker skal kunne sende interne meldinger til andre brukere 23 Varsling En bruker skal kunne følge en bestemt tagg og få varsling når en tråd blir opprettet med denne taggen Lav Lav Dette skal ikke fungere som en instant message service, mer som et meldingssystem med innboks. Ikke funksjonelle krav # Tittel Krav Kommentar 1 Språk Applikasjonen skal være på norsk Applikasjonen skal ikke ha mulighet for å endre språk 2 Brukergruppe Applikasjonens målgruppe skal være studenter i Norge Det skal allikevel åpnes for registrering av brukere uten spesiell skoletilhørighet for å unngå å sperre kunnskapsrike mennesker ute. 3 Plattform Applikasjonen skal utvikles som en Webapplikasjon 4 Brukervennlighet Applikasjonen skal optimaliseres for visning på mindre mobilenheter Webapplikasjonen skal oppleves som en fullverdig nativeapplikasjon 5 Kvalitet Applikasjonen skal oppleves som et ferdig produkt 6 Brukervennlighet Applikasjonens tilpasning til mobile enheter skal ikke gå på bekostning av brukeropplevelsen på PC 7 Testdekning 60% av backend kode skal være dekket av tester Designkrav Designet skal følge en overordnet filosofi om et minimalistisk design, uten forstyrrende elementer. Innhold skal være i fokus Applikasjonen skal ha en enkel farge-palett med få farger, men allikevel gjenkjennelig slik at det er høy gjenkjennelsesfaktor Tekniske krav Applikasjonens back-end skal utvikles i Java med et RESTful API Applikasjonens front-end skal utvikles i AngularJS og Bootstrap Data skal lagres i en MySQL database Krav til kildekode Metodenavn, klassenavn o.l. skal være selvforklarende Kommentering skal ikke være nødvendig, men allikevel være tilstede der omfanget av en metode krever det
Kildekode skal skrives på engelsk Kommentering skal skrives på engelsk Kildekode skal være konsekvent Kildekode skal struktureres på en måte som gjør det enkelt for utvidelser REST-metadata og annotations(slik som @GET, @Path(' ') og @Consumes ) skal skrives i egne Interfaces, ikke i java-klassene Dette gjøres for å skille ut hvordan ting er implementert fra hvordan Front-end skal kommunisere med API-et. Forbedrer leseligheten, og gjør det lettere for front-end utvikleren å forholde seg til backenden. Dokumentkrav Dokumentasjonen skal ikke inneholde unødvendig repetisjon Dokumentasjonen skal ikke inneholde overflødig informasjon Dokumentasjonen skal kun inneholde informasjonsbærende setninger i så stor grad det er mulig Dokumentasjonen skal ikke være i strid med underskrevet avtaler fra Accenture Rammekrav Applikasjonen skal kjøre på en Amazon Cloud Server, slik at oppetiden vil være høy Det skal eksistere en automatisk backupløsning av databasen slik at datatapet ikke blir stort ved eventuell disk-kræsj Programvare og utviklingsverktøy Programvare/Tjeneste/Teknologi Bruksområde Kommentar Gradle Jira Build-verktøy Dependency-manager Issue-tracking Bug-håndtering Confluence Dokumentdeling Følgende dokumentasjon skal legges inn i Confluence: Styringsdokumentasjon Referater/Dagbøker/Logger Produktdokumentasjon Ved endt prosjekt skal dokumentasjonen fra Confluence danne grunnlag for rapporten vi skal utarbeide InnerSource, Git Versjonskontroll InnerSource Accentures egen versjonskontroll-platform, bruker Git Jenkins Build-platform IntelliJ / Eclipse IDE Med Git/Gradle-plugins og plugins for testing Gedit/Sublime Text/Notepad++ Teksteditor Brukes "on the fly" av alle gruppemedlemmene til småting, ikke nødvendig å bli enige om en egen standard Java m. Jersey Backend REST-api Jersey er en implementasjon av JAX-RS 2.0 API-et Java 32bit skal brukes, JDK 7 Apache Tomcat / Jetty Http-server Brukes til å kjøre Java-servleten MySQL Databaseløsning AngularJS Bootstrap Frontend Javascript rammeverk Frontend Javascript rammeverk Utførerer spørringene mot REST-api-et Gir støtte for frontendutvikling spesialtilpasset for enheter med forskjellige skjermstørrelser Lync IM-klient For kommunikasjon mellom gruppen og veiledere. Skype IM-klient Kommunikasjon gruppemedlemmene imellom. Brukes til "spontan"-møter, eller når noen har vært borte og trenger oppdatering. JUnit Testbibliotek Java Utviklingspråk for backend
Metodevalg Utviklingsmetodikken vi har valgt er Test Driven Development (TDD) og SCRUM. Vi skal ha en sprintlengde på 2 uker. Dette gir oss totalt 6 sprinter. Ved å velge Test Driven Development er vi sikre på at systemet er godt testet gjennom hele utviklingsperioden. Ved å skrive gode tester under utvikling får vi også et veldig veltestet system ved prosjektslutt. Ved å benytte TDD vil man også være forsikret om at utvikleren som skriver koden hele tiden er bevisst hva koden som blir skrevet skal gjøre. Siden man har fokus på å få testene til å passere, ender man opp med kode som gjør det som er nødvendig, men ikke mer. Vi har ikke tidligere jobbet med TDD-metodikken, men har erfaring med å skrive enhetstester så vi anser dette som en utfordring, men ikke noe problem. Use case Følgende "use cases" skal demonstrere hovedfunksjonene for system funksjonalitetene i applikasjonen. Use Case 1 - Demonstrere at man kan opprette bruker og stille et spørsmål med tagger Kari gjør oppgaver rundt fysikk, og har ikke helt forståelse for Newtons lover og finner frem til "studass", hun har aldri brukt dette før så hun oppretter en ny bruker. Etter å ha opprettet denne brukeren poster hun inn et innlegg som hun tagger med taggene "fysikk" og "HiOA". Use Case 2 - Demonstrere søkefunksjonen og hvordan man kan svare på spørsmål Ola er ute etter å finne ut hvilke emner i diskret matte som mange synes er vanskelig slik at han kan øve spesielt på dette til eksamen. Når han da søker med taggen "diskret matte" så kommer han over et spørsmål/tema som han har ganske kontroll på, han skriver et utfyllende svar på det trådstarter lurer på og poster dette. Use Case 3 - Demonstrere at man kan gi poeng til svar og spørsmål Hans er inne på "studass" å leter etter et svar på en oppgave han sitter med i kjemi. Han finner frem til et spørsmål som er akkurat det samme han lurer på. Dette spørsmålet har 2 svar, det ene svaret synes Hans ikke var lite utfyllende så han velger å gi dette svaret et minuspoeng. Mens svaret under som er nyere, var mer utfyllende så han velger å gi dette en poeng, slik at dette kan komme høyere opp når neste bruker er å lurer på det samme. Use Case 4 - Demonstrere "glemt passord" funksjonen og logg ut Line skulle skrive et spørsmål, men da fikk hun en advarsel at man måtte logge inn først. Passordet hadde Line glemt så hun trykket på "glemt passord" og får en e-post med en link som hun trykker på slik at hun kan lage seg et nytt passord, og postet spørsmålet.
Risikoevaluering I risikoevaluering er det viktig at vi ser på forskjellige risikoer som kan oppstå. Vi bruker en tabell for å vise fram sannsynlighet,konsekvenser og tiltak som kan iverksettes. Årsåk Sannsynlighet Konsekvenser Tiltak Sykdom i gruppen Stor Viktig at personen som er syk melder ifra og isolerer seg fra resten av gruppen i fare for smitte. Arbeidsoppgaver kan utføres hjemmefra med kommunikasjon fra gruppen. Juridisk risiko All info som blir lastet opp skal være i henhold til vilkår og betingelser samt personvern. Der det er definert at alt man laster opp eier man copyright på selv. Evt. hvis noen laster opp uten lov, så er konsekvensen at man får en take-down-request. Tap av datamaskin eller hardware-feil Dårlig samarbeid innad i gruppen Miste et gruppemedlem Liten Accenture låner ut bærbare maskiner og de kan erstattes ved feil eller mangler. Tap av kildekode anser vi ikke som noe stort problem, da vi kontinuerlig vil benytte oss av et kildekontrollsystem. Perioden et gruppemedlem eventuelt mangler datamaskin kan par-programmering benyttes. Lav Konflikter som oppstår mellom gruppemedlemer som stanser framgang i prosjektet løses ved hjelp av veiledning fra gruppeveileder. Går det for mye tid til konflikter må oppgavene fordeles på nytt. Lav Stor Oppgaver må fordeles og prioriteres på nytt. Målene som er satt tidligere må endres for at prosjektet vil bli oppnåd.
Tap av data Lav Lav All kode skrevet blir lagret på nettskylagring, backup blir tatt lokalt og flere på gruppen har koden. Det går fort å gjenopprette prosjektet ved hjelp av andres kopier. Logisk datamodell