KRAVSPESIFIKASJON FOR SOSIORAMA Innhold 1. Forord... 2 2. Definisjoner... 3 3. Innledning... 4 3.1 Bakgrunn og formål... 4 3.2 Målsetting og avgrensninger... 4 4. Detaljert beskrivelse... 8 4.1 Funksjonelle krav... 8 4.1.1 Alle brukere... 8 2.1.2 Uregistrerte brukere... 8 2.1.3 Registrerte brukere... 8 2.1.4 Alle kanaleiere... 9 2.1.5 Registrerte kanaleiere... 9 2.1.6 Alle kanaler... 9 2.1.7 Uregistrerte kanaler... 10 2.1.8 Registrerte kanaler... 10 2.1.9 Spesifikt for administrasjon... 10 2.2 Ikke- funksjonelle krav... 10 2.2.1 Antall brukere samtidig/ytelse... 10 2.2.2 Sikkerhet... 10 2.2.3 Responstid... 10 2.2.4 Brukervennlighet... 11 2.2.5 Vedlikehold... 11 1
1. Forord Kravspesifikasjonen er et dokument med de kravene vi har satt til Sosiorama-systemet. Denne har utviklet seg fra den svært omfattende versjonen vi hadde etter første runde med idéer og drøftinger av hva Sosiorama skulle være. Dokumentet er skrevet både for at vi selv skal kunne etterprøve våre krav, men også for at andre skal kunne se hva systemet oppfyller per i dag. Utviklingen har skjedd på grunn av nye erfaringer, men også fordi vi har prioritert nøkkelfunksjonalitet mot prosjektets slutt. Punktene som er listet opp i dette dokumentet er implementert både på klient og på server. 2
2. Definisjoner Klient: Chatklient som kjører på Android. Server: Tjener som muliggjør utveksling av informasjon mellom klienter og som utfører nødvendige databaseoperasjoner og forretningslogikk. Bruker: En bruker er en fysisk person som benytter seg av en klient. Profil: I essens det samme som en tradisjonell brukerkonto med tilknyttet brukernavn og passord. I Sosiorama vil det være ekstra informasjon tilknyttet en profil for registrerte brukere. Nick: Dette er ditt chatnavn. Knyttet til en bruker, men ved å ha flere profiler kan en bruker også ha flere nick. Uregistrert bruker: En bruker som kobler seg på server med klient, men som ikke har registrert seg med profil på server. Registrert bruker: En bruker som er registrert med en eller flere profiler på server. Kringkasting: En kanal kringkastes utover et område. Kanaleier: En kanaleier er den som har opprettet en kanal, dette nicket har suverene rettigheter på kanalen. Kanalnavn: Navnet chatklientene får opp som navn på kanalen er abstrahert fra IRC- kanalnavnet til kanalen. Lokasjon: Geografisk posisjon som oppgis ved hjelp av latitude og longitude. Lokasjonsnav: Den kanaleier som er midtpunktet i en geografisk utspent kanal. 3
3. Innledning 3.1 Bakgrunn og formål Det finnes i dag ingen utbredte og gode systemer for å komme raskt og enkelt i kontakt med andre mennesker som befinner i samme område, og fortrinnsvis med samme interesser, uten å allerede ha delt personlig informasjon som f.eks telefonnummer. Ved større arrangementer hvor f.eks. medlemmer av et nettsamfunn ønsker å møtes, kunne disse enkelt kobles inn på en kanal bestemt av en viss geografisk rekkevidde, og de kunne således enkelt kommunisere og evt. avtale møtested. Kanaler kan opprettes for å kringkaste eksistensen av f.eks. en konsert, og i større byer vil dette kunne gi deg en ny dimensjon i opplevelsesbildet. Du kan rett og slett delta spontant på arrangementer du ellers ikke hadde visst om. Det kan være seg en kunstutstilling, bilmesse etc. Dette ønsker vi å realisere med vårt prosjekt Sosiorama. 3.2 Målsetting og avgrensninger Målsetning med dette dokumentet er å lage en beskrivelse av krav for klient- server systemet Sosiorama. Dvs. hva systemet skal inneholde, og ikke detaljert hvordan systemets egenskaper skal implementeres. Vi har bestemt oss for å bruke InsipIRCd for Linux som IRC- server. Denne kan utvides med egenprogrammerte moduler for ekstra funksjonalitet. For klienten har vi valgt å benytte oss av IRCLib for Android, dermed trenger vi ikke tenke på detaljer ifb. med IRC- protokollen, men vi må likevel utvikle forretningslogikk og presentasjon (GUI). For klientposisjonering vil vi benytte GPS og triangulering. 4
Skisse 1. Klient- server systemet Sosiorama 5
Skisse 2. Eksempel på kanal med begrenset geografisk rekkevidde. 6
Skisse 3. GPS og triangulering. 7
4. Detaljert beskrivelse 4.1 Funksjonelle krav 4.1.1 Alle brukere Få opplistet kanaler innenfor kanaldefinert rekkevidde. Gå inn på åpne kanaler uten autentisering. Chatte i kanaler man deltar i. Opprette uregistrert kanal. Sende privatmeldinger til andre brukere. Benytte seg av standard irc- kommandoer. 2.1.2 Uregistrerte brukere Klientlagring av profil(er): Nick Passord E- post 2.1.3 Registrerte brukere Autentisere seg med nick og passord. Ha mulighet til å registrere kanaler. Kunne blokkere andre brukere. A. Søkbarhetsnivå Ha mulighet til å endre til søkbarhetsnivå, altså i hvilken grad andre brukere kan få opp vedkommende i søk eller motta varsler om at vedkommende er i samme område. Søkbar for ingen Søkbar for venner Søkbar for alle B. Venner Kunne sende venneforespørsel til annen bruker Ha mulighet for å akseptere eller avvise venneforespørsel. Ha mulighet for å fjerne venn. C. Varsler Få varsel når venner av brukeren er i nærheten. Få varsel når andre som deler samme interesse som brukeren er i nærheten. 8
Få varsel når man entrer en kanal der en blokkert bruker oppholder seg. Få varsel for privatmeldinger D. Profil Legge til og endre egen profilinformasjon: o Fullt navn o Interesser o Bilde o E- mail o Telefonnummer o Web- side o Beskrivelse o Alder o Kjønn E. Søk Kanalsøk på tilgjengelige kanaler (som favner over klientens lokasjon.) Kanalsøk på brukerdefinert radius. Kanalsøk på nøkkelord i kanalnavn og topic Brukersøk generelt på brukere i nærheten Brukersøk på brukere i nærheten med en eller flere sammenfallende interesser Brukersøk på venner i nærheten Brukersøk på ord i brukerbeskrivelse Brukersøk på alder Brukersøk på kjønn Brukersøk på nickname 2.1.4 Alle kanaleiere Bytte topic/emne på kanal Sette navn på kanal 2.1.5 Registrerte kanaleiere Definere egen rekkevidde på kanalen 2.1.6 Alle kanaler Skal ha fast posisjon. Skal ikke kaste ut brukere når noen kommer utenfor rekkevidden til kanalen etter at de har gått inn på den. I hovedsak skal kun kanaler hvis rekkevidde dekker din posisjon, komme opp i dine kanalsøk. 9
2.1.7 Uregistrerte kanaler Kan ikke eksistere uten aktive brukere. Skal ha fast definert kringkastingsrekkevidde. Skal kunne registreres. 2.1.8 Registrerte kanaler Rekkevidde skal kunne endres. 2.1.9 Spesifikt for administrasjon Systemadministrator er øverste myndighet i systemet. 2.2 Ikke- funksjonelle krav 2.2.1 Antall brukere samtidig/ytelse Løsningen skal ta høyde for at den potensielt kan få flere millioner brukere. Det må derfor velges en eksisterende server som skalerer godt, blant annet ved å ha mulighet for å linke flere servere sammen for å spre lasten. Klienten må også være kodet slik at den ikke belaster serveren mer enn nødvendig. 2.2.2 Sikkerhet Løsningen skal formidle til brukerne at den informasjonen brukerne skriver inn om seg selv ikke trenger å være reell. Det er altså ingen påkrevd identifisering for brukere. Det vil allikevel være mulighet for å registrere kallenavn og autentisere seg med dette kallenavnet. IRC er en protokoll som sendes i ren tekst. Vi vil om vi har ressurser og tid til det implementere kryptert kommunikasjon i systemet. Passord vil lagres kryptert i databasen for registrerte brukere. 2.2.3 Responstid Serveren må stå på raske linjer med passe lav responstid slik at brukerne ikke opplever unødvendig forsinkelse. Under prosjektet skal det settes opp en server i Norge, men det kan senere være aktuelt å utvide med servere i utlandet etter behov. Latenstiden er ikke like kritisk som på spillservere, og det vil for eksempel være akseptabelt med 200 ms ping for klienter i utlandet. Utviding vil derfor skje hovedsakelig etter behov for mer båndbredde eller prosesseringskraft i forbindelse med et økende antall klienter. 10
2.2.4 Brukervennlighet Applikasjonen skal ha en veldig lav brukerterskel, slik at det er enkelt å komme i gang. Brukeren skal derfor ikke trenge å velge noe annet enn kallenavn for å få koblet på og snakke med andre. Brukeren skal ikke skal behøve å skrive kommandoer for å utføre mye av den typiske IRC- funksjonaliteten. 2.2.5 Vedlikehold Serveren skal i så stor grad som mulig tilpasses med moduler, med minst mulig endringer i den underliggende koden. På den måten kan det oppgraderes versjoner hvis det kommer sikkerhetsoppdateringer. Eventuelle endringer i selve serverkoden må markeres svært godt slik at det går an å videreføre disse på en enkel måte. 11