Kravspesifikasjon. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Transkript

1 Kravspesifikasjon Magne Rodem og Jan-Erik Strøm 18. juni 2006

2 Innhold 1 Introduksjon 3 2 Overordnet systembeskrivelse Bakgrunn for prosjektet Funksjoner og rutiner som dekkes av systemet Krav til nytt system Krav til funksjoner Use case diagram Formulering av use casene på høyt nivå Fullstendig use case for UC1: Autentiser bruker Fullstendig use case for UC2: Bla i kontakter Fullstendig use case for UC3: Finn kontakt(er) Fullstendig use case for UC4: Ring kontakt Fullstendig use case for UC5: Send tekstmelding til kontakt Fullstendig use case for UC6: Lagre kontakt Fullstendig use case for UC7: Send kontakt som vcard Krav til data Krav til egenskaper Brukbarhet Ytelse Pålitelighet Implementasjonsrammer Komponenter basert på åpen kildekode Dokumentasjon Litteraturliste 18 6 Revisjonshistorie 19 2

3 1 Introduksjon Kravspesifikasjonen utarbeides for å dokumentere de krav som stilles til systemet. Det skal bestemmes og detaljføres hva slags system som skal lages. Det lages dessuten en oversikt over systemet som skal være til hjelp for gruppa i selve utviklingsprosessen. Hensikten med dette dokumentet er todelt. For det første skal brukernes krav til systemet være dokumentert. Dette gjøres ved hjelp av use case på høyt nivå og dokumentasjon av krav til egenskaper, ytelse og pålitelighet. I tillegg gjøres det klart hvilke dokumenter som skal leveres sammen med systemet. Den andre delen av kravdokumentet omhandler detaljerte og teknisk spesifikke krav til systemet. Disse kravene skal være av en slik art at en utviklingsgruppe skal få et godt nok grunnlag for å utvikle systemet. For å dokumentere disse kravene, utarbeides en use case på lavt nivå, samt krav til de data som systemet skal behandle. Vi vil i hovedsak i dette prosjektet forsøke å jobbe iterativt med kravanalyse og design, koding og testing, ved å følge livsløpsmodellen UP (Unified Process). Det betyr at dette dokumentet vil endre seg i framtidige iterasjoner, både med hensyn på reviderte krav og tilleggelse av nye krav som dukker opp. Vi vil altså ikke følge en standard fossefallsmodell, hvor det legges mye vekt på å definere alle krav på en meget detaljert måte før man går i gang med design og koding. Et slikt opplegg vil som regel føre til mye unødvendig arbeid, da krav har en tendens til å endre seg, eller nye krav vil dukke opp, når vi setter i gang med implementasjonsfasen. Vi ønsker derfor å være mest mulige fleksible når det gjelder krav, og vil følge de beste praksiser som inngår i UP. Det betyr at hovedvekten i denne kravspesifikasjon vil ligge på å få fram krav gjennom use caser, både på høyt og lavt nivå. Krav som ikke er mulige å få fram med use caser, vil inngå i en egen seksjon. For mer informasjon om UP, se oppføring på Wikipedia om Unified Process. [3] Kapittel 2 presenterer er overordnet beskrivelse av det systemet som skal utvikles. Her blir bakgrunnen for prosjektet beskrevet, og hovedfunksjonene blir beskrevet på et høyt nivå. Hensikten er å skaffe leseren en oversikt over det som senere vil beskrives mer detaljert. Kapittel 3 er hovedkapittelet. Her beskrives de krav som er til systemet i detalj gjennom use caser. Det beskrives også de krav til data som inngår i systemet. Ved utarbeidelse av use casene har vi benyttet metoder spesifisert i Applying UML and patterns. [1] Kapittel 4 beskriver de krav som går på egenskaper til systemet. Dette er et supplement til funksjonskravene og beskriver krav som er vanskelige å få fram ved hjelp av use caser. 3

4 2 Overordnet systembeskrivelse 2.1 Bakgrunn for prosjektet Telenor Mobil tilbyr i dag tjenesten ProffNett til sine bedriftskunder. Denne tjenesten fungerer som en hussentral på mobilen som blant annet gir brukerne økt fleksibilitet og mulighet til å styre egen tilgjengelighet. Brukerne kan selv stille inn hvordan innkommende anrop skal behandles når de er opptatt eller ikke tilgjengelig. Dette kan gjøres via Internett, WAP eller på mobiltelefonen. Kunder som tilhører samme interne ProffNett vil også blant annet kunne ringe gratis til hverandre. ProffNett har allerede en nettsentrisk adressebok som er tilgjengelig via et web-basert grensesnitt. Da brukerne av ProffNett ikke alltid har tilgang til PC med Internettoppkobling, vil det være hensiktsmessig å kunne aksessere adresseboken direkte fra telefonen via en J2ME-applikasjon. På denne måten vil brukerne ideelt sett slippe å legge inn numrene til sine kollegaer manuelt i sin lokale adressebok. 2.2 Funksjoner og rutiner som dekkes av systemet Systemet består av en tjener og en klient: Tjener En J2ME-applikasjon vil måtte kontakte en tjener for å aksessere ProffNett-databasen. Denne vil være i form av en Web service 1 som har et sett med metoder spesifisert i sitt grensesnitt. Ved kall på disse metodene må klienten sende med A-nr (og eventuelt passord) for å autentisere seg. Tjeneren vil administreres av teleoperatør. Klient Kliente i systemet vil være en applikasjon som kjører på brukernes mobiltelefoner. En slik applikasjon vil kunne være ferdig installert og oppsatt i det kunden mottar telefonen, eller kunden vil kunne hente ned applikasjonen selv ved å besøke en URL. Fra applikasjonen vil brukeren kunne ringe til, sende SMS til eller lagre de telefonnumrene som befinner seg i ProffNett-databasen. Applikasjonen vil ha et enkelt og attraktivt brukergrensesnitt, og vil integreres så tett som mulig med mobiltelefonen. 1 W3C (World Wide Web Consortium) definerer en Web service som a software system designed to support interoperable machine-to-machine interaction over a network. Dens grensesnitt er beskrevet i XML, og andre systemer tar kontakt med den ved å benytte de metoder som er beskrevet i grensesnittet. Programvare skrevet i ulike programmeringsspråk og som kjører på ulike plattformer kan bruke Web services til å utveksle data over nettverk. Se oppføring på Wikipedia om Web services. [2] 4

5 Ut fra denne kortfattede beskrivelsen av de to hoveddelene kommer vi fram til følgende funksjoner som kreves av systemet: Autentisering av bruker For å laste ned applikasjonen må brukerne sende en tekstmelding til et gitt nummer med f.eks. teksten PROFFNETT. Da vil en tjener hos Telenor generere et passord som sammen med brukerens nummer legges inn i en konfigurasjonsfil og distribueres sammen med applikasjonen. Ved oppstart av applikasjonen leses konfigurasjonsfilen, og nummeret og passordet benyttes ved hver forespørsel mot tjeneren. Søk i adressebok En bruker vil i applikasjonen kunne taste inn et navn for å søke i adresseboka. Applikasjonen vil da kalle opp tjeneren, som utfører en spørring mot ProffNett-databasen. Resultatene av spørringen vil bli sendt tilbake til applikasjonen. Utlisting av adressebok En bruker kan velge å få vist en liste over alle nummer i adresseboka. Da adresseboka kan være stor, vil tjeneren kun sende et visst antall nummer om gangen. Brukeren vil da kunne lete seg frem blant numrene i adresseboka. Oppringing av telefonnummer Når en bruker har funnet det nummeret han var på jakt etter, vil han kunne få valget om å ringe det aktuelle nummeret direkte fra applikasjonen. Telefonsamtaler internt i ProffNett er som kjent uten kostnad for brukeren. Sending av SMS til telefonnummer En bruker vil også kunne benytte applikasjonen til å sende en SMS til et av numrene i adresseboka. Brukeren vil få opp et tekstområde der meldingen kan tastes inn på samme måte som ved vanlig sending av SMS. Sending av vcard En bruker vil kunne sende en kontakt til en annen mobiltelefon i form av et vcard[4]. Brukeren velger hvilken kontakt som skal sendes, og taster deretter inn telefonnummeret som kontakten skal sendes til. Lagring av kontakt En bruker vil kunne lagre en kontakt i adresseboka til sin lokale kontaktliste slik at kontakten kan nås hurtig på et senere tidspunkt. 5

6 3 Krav til nytt system 3.1 Krav til funksjoner Use case diagram Følgende use case diagram viser systemets hovedoperasjoner: Figur 1: Use case diagram 6

7 3.1.2 Formulering av use casene på høyt nivå UC1: Autentiser bruker Ved oppstart av applikasjonen henter applikasjonen fram telefonnummer og passord fra en konfigurasjonsfil. Denne filen ble vedlagt applikasjonen ved nedlasting fra Telenor. Telefonnummeret og passordet sendes med sammen med alle forespørsler mot tjeneren. Ved å se på telefonnummeret kan tjeneren avgjøre hvilken gruppe brukeren hører til, og kun kontakter som befinner seg i samme gruppe vil bli hentet ned. UC2: Bla i kontakter Brukeren kan velge å bla i de tilgjengelige kontaktene. På grunn av begrenset overføringshastighet, skal det kun være mulig å bla i 10 kontakter på en gang. Det skal være mulig å navigere seg lett gjennom kontaktene. Brukeren må belage seg på en liten pause ved nedlasting av nye kontakter, men denne skal være så kort som mulig. UC3: Finn kontakt(er) Brukeren kan søke etter en bestemt kontakt hvis han vet navn eller annen informasjon om kontakten. Det skal primært gis mulighet for å søke på fornavn eller etternavn. Søkefunksjonen skal kun finne kontakter som er registrert i samme ProffNett-avtale som brukeren. UC4: Ring kontakt Når brukeren har funnet det nummeret han var på utkikk etter, skal han gis muligheten til å ringe dette nummeret direkte. J2ME-klienten må da kjøre plattform-kall mot brukerens mobiletelefon for å få utført oppringingen. Klienten skal om mulig ligge å vente i bakgrunnen mens oppringingen og eventuelt samtalen pågår. Dette vil variere ut ifra hvilken type mobiltelefon klienten kjøres på. UC5: Send tekstmelding til kontakt I likhet med UC4: Ring kontakt, skal J2ME-klienten kjøre plattform-kall mot brukerens mobiltelefon for å få opp grensesnittet for innskriving av tekstmelding. Klienten skal om mulig ligge å vente i bakgrunnen mens tekstmeldingen konstrueres og sendes. Dette vil variere ut ifra hvilken type mobiltelefon klienten kjøres på. UC6: Lagre kontakt Brukeren skal ha mulighet til å lagre kontakten i adresseboken på sin mobiltelefon. Dette skal skje automatisk, og klienten må da ta i bruk mobiltelefonens muligheter for lagring av kontakter. Det skal primært lagres navn og nummer. UC7: Send kontakt som vcard Brukeren kan sende en kontakt på vcard-format til en annen mobiltelefon. Dette gjøres ved at brukeren finner fram til kontakten som skal sendes og velger Send som vcard. Deretter taster brukeren inn et nummer, og vcardet sendes til dette nummeret. 7

8 3.1.3 Fullstendig use case for UC1: Autentiser bruker System: J2ME-applikasjon for nettsentrisk adressebok. Nivå: Brukermål. Primæraktør: Mobiltelefonbruker. Interesseparter: Mobiltelefonbruker: Ønsker å beskytte sine private data. Teleoperatør: Ønsker mest mulig sikkerhet rundt innloggingsprosessen. Forhåndskrav: En konfigurasjonsfil med telefonnummer og passord må være vedlagt applikasjonen (skjer ved nedlasting fra teleoperatør). Suksessgaranti: Brukeren får autentisert seg og får dermed tilgang til kontaktene i sin gruppe. Hovedflyt: 1. Mobiltelefonbrukeren starter applikasjonen. 2. Applikasjonen leser en konfigurasjonsfil som inneholder telefonnummer og passord. 3. Telefonnummeret og passordet blir brukt i alle forespørsler mot tjeneren for å sikre at sikkerheten blir ivaretatt. Alternative flyter: 1. (a) Applikasjonen finner ikke konfigurasjonsfilen. (b) Applikasjonen viser en feilmelding som forklarer at brukeren ikke kan autentiseres, og foreslår at applikasjonen lastes ned på nytt. (c) Applikasjonen avsluttes. Teknologi- og datavariasjonsliste: På mobiltelefonen benyttes Wingfoot SOAP; en lettvekts klientimplementasjon av SOAP 1.1. På tjeneren benyttes Suns applikasjonsserver. Passordet er kryptert med MD5. Hyppighet: Kan skje kontinuerlig. Åpne punkter: Forbindelsen mellom klient og tjener er ikke kryptert. Dette bør gjøres av sikkerhetshensyn Fullstendig use case for UC2: Bla i kontakter System: J2ME-applikasjon for nettsentrisk adressebok. Nivå: Brukermål. Primæraktør: Mobiltelefonbruker. Interesseparter: Mobiltelefonbruker: Har interesse av å få en liste over de nummer og navn som er registrert i adresseboka. 8

9 Teleoperatør: Ønsker å ha et effektivt og intuitivt brukergrensesnitt mot adresseboka slik at kundene vil benytte seg av tjenesten. Forhåndskrav: Mobiltelefonbrukeren må ha åpnet applikasjonen. Suksessgaranti: Suksess hvis brukeren får en liste over nummer og navn. Hovedflyt: 1. Mobiltelefonbrukeren velger Vis liste over kontakter. 2. Applikasjonen tar kontakt med tjeneren. 3. Tjeneren sender en spørring mot kontaktdatabasen etter de ti neste kontaktene som tilhører samme gruppe som mobiltelefonbrukeren. 4. Tjeneren returnerer de ti kontaktene til applikasjonen. 5. Applikasjonen viser kontaktene på skjermen. 6. Mobiltelefonbrukeren blar gjennom kontaktene og velger Neste. Punkt 2-6 gjentas til brukeren har funnet ønsket kontakt eller avbryter. Alternative flyter: 1. (a) Applikasjonen får ikke kontakt med tjeneren. (b) Applikasjonen avbryter operasjonen. (c) Applikasjonen viser en feilmelding som forklarer problemet. Teknologi- og datavariasjonsliste: På mobiltelefonen benyttes Wingfoot SOAP; en lettvekts klientimplementasjon av SOAP 1.1. På tjeneren benyttes Suns applikasjonsserver. Hyppighet: Kan skje kontinuerlig. Åpne punkter: Hvordan vil kontaktlisten se ut på ulike mobiltelefonmodeller? Hvordan vil kontaktlisten se ut ved forskjellige skjermoppløsninger? Hvor raskt vil kontaktlisten lastes? 9

10 3.1.5 Fullstendig use case for UC3: Finn kontakt(er) System: J2ME-applikasjon for nettsentrisk adressebok. Nivå: Brukermål. Primæraktør: Mobiltelefonbruker. Interesseparter: Mobiltelefonbruker: Har interesse av å finne informasjon om en bestemt kontakt som er registrert i adresseboka. Teleoperatør: Ønsker å ha et effektivt og intuitivt brukergrensesnitt mot adresseboka slik at kundene vil benytte seg av tjenesten. Forhåndskrav: Mobiltelefonbrukeren må ha åpnet applikasjonen. Suksessgaranti: Suksess hvis brukeren får en liste over kontakter som stemmer de aktuelle søkekriteriene. Hovedflyt: 1. Applikasjonen viser et tekstfelt der brukeren kan taste inn navnet på en kontakt. 2. Mobiltelefonbrukeren taster inn et navn og velger OK. Resten av denne use casen følger UC2: Bla i kontakter, punkt 2-6. Alternative flyter: 1. (a) Applikasjonen får ikke kontakt med tjeneren. (b) Applikasjonen avbryter operasjonen. (c) Applikasjonen viser en feilmelding som forklarer problemet. 2. (a) Mobiltelefonbrukeren taster ikke inn et navn. (b) Applikasjonen avbryter operasjonen. Teknologi- og datavariasjonsliste: På mobiltelefonen benyttes Wingfoot SOAP; en lettvekts klientimplementasjon av SOAP 1.1. På tjeneren benyttes Suns applikasjonsserver. Hyppighet: Kan skje kontinuerlig. Åpne punkter: Hvordan vil kontaktlisten se ut på ulike mobiltelefonmodeller? Hvordan vil kontaktlisten se ut ved forskjellige skjermoppløsninger? Hvor raskt vil kontaktlisten lastes? 10

11 3.1.6 Fullstendig use case for UC4: Ring kontakt System: J2ME-applikasjon for nettsentrisk adressebok. Nivå: Brukermål. Primæraktør: Mobiltelefonbruker. Interesseparter: Mobiltelefonbruker: Har interesse av å ringe opp en bestemt kontakt direkte uten å måtte notere ned eller lagre telefonnummeret. Teleoperatør: Ønsker å ha et effektivt og intuitivt brukergrensesnitt mot adresseboka slik at kundene vil benytte seg av tjenesten. Forhåndskrav: Mobiltelefonbrukeren må ha markert en kontakt. Suksessgaranti: Suksess hvis brukeren får ringt opp en kontakt. Hovedflyt: 1. Mobiltelefonbrukeren markerer en kontakt. 2. Mobiltelefonbrukeren blar seg ned til et av kontaktens numre. 3. Mobiltelefonbrukeren trykker på nummeret og får opp en meny med ulike alternativer. 4. Mobiltelefonbrukeren velger Ring. 5. Applikasjonen utfører et plattform-kall for oppringing av nummer. Alternative flyter: 1. (a) Applikasjonen klarer ikke å utføre oppringingsfunksjonen. (b) Applikasjonen avbryter operasjonen. (c) Applikasjonen viser en melding om at denne funksjonen ikke er støttet på den aktuelle modellen. Teknologi- og datavariasjonsliste: På mobiltelefonen benyttes Wingfoot SOAP; en lettvekts klientimplementasjon av SOAP 1.1. På tjeneren benyttes Suns applikasjonsserver. Hyppighet: Kan skje kontinuerlig. Åpne punkter: Hvordan vil ulike modeller håndtere oppringing fra J2ME? 11

12 3.1.7 Fullstendig use case for UC5: Send tekstmelding til kontakt System: J2ME-applikasjon for nettsentrisk adressebok. Nivå: Brukermål. Primæraktør: Mobiltelefonbruker. Interesseparter: Mobiltelefonbruker: Har interesse av å sende tekstmelding til en bestemt kontakt direkte uten å måtte notere ned eller lagre telefonnummeret. Teleoperatør: Ønsker å ha et effektivt og intuitivt brukergrensesnitt mot adresseboka slik at kundene vil benytte seg av tjenesten. Forhåndskrav: Mobiltelefonbrukeren må ha markert en kontakt. Suksessgaranti: Suksess hvis brukeren får sendt tekstmelding til en kontakt. Hovedflyt: 1. Mobiltelefonbrukeren markerer en kontakt. 2. Mobiltelefonbrukeren blar seg ned til et av kontaktens numre. 3. Mobiltelefonbrukeren trykker på nummeret og får opp en meny med ulike alternativer. 4. Mobiltelefonbrukeren velger Send tekstmelding. 5. Applikasjonen åpner et vindu for inntasting av tekstmelding. 6. Mobiltelefonbrukeren taster inn en tekstmelding og trykker OK. 7. Applikasjonen utfører et plattform-kall for sending av tekstmeldinger. Alternative flyter: 1. (a) Applikasjonen klarer ikke å kalle tekstmeldingsfunksjonen. (b) Applikasjonen avbryter operasjonen. (c) Applikasjonen viser en melding om at denne funksjonen ikke er støttet på den aktuelle modellen. Teknologi- og datavariasjonsliste: På mobiltelefonen benyttes Wingfoot SOAP; en lettvekts klientimplementasjon av SOAP 1.1. På tjeneren benyttes Suns applikasjonsserver. Hyppighet: Kan skje kontinuerlig. Åpne punkter: Hvordan vil ulike modeller håndtere sending av tekstmeldinger fra J2ME? 12

13 3.1.8 Fullstendig use case for UC6: Lagre kontakt System: J2ME-applikasjon for nettsentrisk adressebok. Nivå: Brukermål. Primæraktør: Mobiltelefonbruker. Interesseparter: Mobiltelefonbruker: Har interesse av å lagre en kontakt i sin lokale adressebok for rask tilgang på et senere tidspunkt. Teleoperatør: Ønsker å ha et effektivt og intuitivt brukergrensesnitt mot adresseboka slik at kundene vil benytte seg av tjenesten. Forhåndskrav: Mobiltelefonbrukeren må ha markert en kontakt. Suksessgaranti: Suksess hvis brukeren får lagret kontakten i sin lokale kontaktliste. Hovedflyt: 1. Mobiltelefonbrukeren har markert en kontakt og velger Lagre kontakt. 2. Applikasjonen lagrer kontakten i brukerens lokale kontaktliste. Alternative flyter: 1. (a) Applikasjonen klarer ikke å lagre kontakten. (b) Applikasjonen avbryter operasjonen. (c) Applikasjonen viser en melding om at denne funksjonen ikke er støttet på den aktuelle modellen. Teknologi- og datavariasjonsliste: På mobiltelefonen benyttes Wingfoot SOAP; en lettvekts klientimplementasjon av SOAP 1.1. På tjeneren benyttes Suns applikasjonsserver. Hyppighet: Kan skje kontinuerlig. Åpne punkter: Hvordan vil ulike modeller håndtere aksess mot den lokale kontaktlista fra J2ME? Fullstendig use case for UC7: Send kontakt som vcard System: J2ME-applikasjon for nettsentrisk adressebok. Nivå: Brukermål. Primæraktør: Mobiltelefonbruker. Interesseparter: Mobiltelefonbruker: Har interesse av å dele kontakter med andre. Teleoperatør: Ønsker å ha et effektivt og intuitivt brukergrensesnitt mot adresseboka slik at kundene vil benytte seg av tjenesten. Forhåndskrav: Mobiltelefonbrukeren må ha markert en kontakt. Suksessgaranti: Suksess hvis brukeren får sendt vcardet til en annen telefon. Hovedflyt: 13

14 1. Mobiltelefonbrukeren har markert en kontakt og velger Send kontakt som vcard. 2. Applikasjonen viser en tekstboks der brukeren kan taste inn et telefonnummer. 3. Mobiltelefonbrukeren taster inn et telefonnummer og trykker OK. 4. Applikasjonen sender et vcard til nummeret som brukeren tastet inn. Alternative flyter: 1. (a) Applikasjonen klarer ikke å kalle tekstmeldingsfunksjonen. (b) Applikasjonen avbryter operasjonen. (c) Applikasjonen viser en melding om at denne funksjonen ikke er støttet på den aktuelle modellen. Teknologi- og datavariasjonsliste: På mobiltelefonen benyttes Wingfoot SOAP; en lettvekts klientimplementasjon av SOAP 1.1. På tjeneren benyttes Suns applikasjonsserver. Hyppighet: Kan skje kontinuerlig. Åpne punkter: Hvordan vil ulike modeller håndtere sending av tekstmeldinger fra J2ME? 14

15 3.2 Krav til data En database er nødvendig for å ta vare på alle data om systemets brukere. Telenor opererer med flere ulike databaser, og i vårt tilfelle er det to som er relevante. Dette er S212 (inneholder personopplysninger) og MCX (benyttes av ProffNett). MCX synkroniseres jevnlig opp mot S212. Vi har på nåværende tidspunkt ikke tilgang til disse, og har fått indikasjoner fra oppdragsgiver om at dette kan ta tid. Vi har derfor foreløpig satt opp en minimal fiktiv databasestruktur. Den ser slik ut: Figur 2: En fiktiv datamodell En kontakt lagres med fornavn, etternavn, telefonnummer og passord i Contact-tabellen. Det telefonnummeret som står oppført her, sammen med passordet, brukes for å autentisere brukeren når han benytter klientapplikasjonen. Dette betyr at man må være registrert som kontakt før man kan bruke klienten, noe som er logisk siden adresseboken er ment å være et oppslagsverk for bedriften. En kontakt tilhører en bestemt gruppe. En bruker av klientapplikasjonen har bare tilgang til kontakter innenfor samme gruppe som seg selv. I Info-tabellen ligger de ulike typer av informasjon som kan legges til på en kontakt. Dette kan være ting som mobilnummer, adresse, epost, o.l. Vi har designet det slik at informasjonen er lagret i radene i tabellen istedet for kolonnene. På den måten slipper vi å endre databasestrukturen skulle det være behov for å utvide med ny type informasjon. Det er da bare å legge til en ny rad i tabellen. Endringen vil på den måten også reflekteres umiddelbart i klientapplikasjonen. 15

16 Under følger en oversikt over de feltene som inngår i tabellene, og hvilke datatyper som brukes: Felt Verditype Størrelse Påkrevd Kommentar Info.id heltall - primærnøkkel Info.type heltall - - Info.label tekst 45 - Contact.contactId heltall - primærnøkkel Contact.groupId heltall - fremmednøkkel ref ContactGroup Contact.lastName tekst 45 - Contact.firstName tekst 45 - Contact.phoneNumber tekst 11 - Contact.password tekst 50 kryptert ContactGroup.groupId heltall - primærnøkkel ContactGroup.groupName tekst 60 - ContactInfo.contactId autonummer - fremmednøkkel ref Contact ContactInfo.infoId autonummer - fremmednøkkel ref Info ContactInfo.text tekst

17 4 Krav til egenskaper 4.1 Brukbarhet Brukergrensesnittet skal være oversiktelig og enkelt. Brukeren skal med en gang skjønne hva han må gjøre for å slå opp i adresseboka. Applikasjonen skal fungere på et utvalg av mobiltelefoner, og utvikles spesielt mot én bestemt modell. Søk skal være tilgjengelig på forsiden til applikasjonen, da dette kommer til å være den mest brukte funksjonen. Tekst skal være lett å lese. Applikasjonen skal ikke være til hinder for vanlig bruk av mobiltelefonen. Ved anrop eller andre hendelser skal applikasjonen legge seg i bakgrunnen. 4.2 Ytelse Dersom en bruker er oppkoblet mot adresseboka, skal det ikke ta mer enn fem sekunder å søke opp et nummer, og ideelt sett skal resultatet presenteres innen ett sekund. Da mobiltelefoner har begrenset minne, lagringskapasitet og nettverkshastighet, må ressursbruken begrenses til et absolutt minimum. Programmet skal ikke okkupere mer enn 100kB i telefonens minne. Brukeren skal ikke oppleve lengre pauser som følge av datatrafikk. Datatrafikken skal separeres i egne tråder. 4.3 Pålitelighet Interne feil i applikasjonen skal ikke påvirke brukeren. En bruker skal slippe å få kryptiske meldinger. Systemet skal være modularisert, slik at lokalisering og retting av feil skal gå raskt. 17

18 4.4 Implementasjonsrammer Klient-applikasjonen skal utvikles med J2ME (Java 2 Micro Edition)-teknologi. Den fiktive databasen skal opprettes i mysql. Denne delen kommer til å bli byttet ut, og det er viktig å abstrahere databasekommunikasjonen slik at dette blir tatt hensyn til. Databasekommunikasjonen skal være uavhengig av databasesystem. 4.5 Komponenter basert på åpen kildekode Følgende eksterne komponenter vil bli benyttet i prosjektet: Wingfoot, lettvekts klientimplementasjon av SOAP 1.1. kxml for parsing av XML på mobiltelefonene. 4.6 Dokumentasjon Følgende dokumentasjon skal leveres sammen med systemet: Installasjonsveiledning. Designdokument. Sluttrapport. Whitepaper på engelsk. Tittelside og presentasjon. Timelister og statusrapporter. 5 Litteraturliste [1] Applying UML and patterns, third edition, side Craig Larman, 2005, ISBN: [2] Web service på Wikipedia service [3] Unified Process på Wikipedia Process [4] vcard på Wikipedia 18

19 6 Revisjonshistorie Dato Versjon Beskrivelse Første utgave Revidert etter tilbakemelding fra veileder Oppdatert seksjonen Krav til data Ferdigstilte dokumentet til innlevering. 19