Entobutikk 1.KRAVSPESIFIKASJON VÅR 2011

Transkript

1 1.KRAVSPESIFIKASJON VÅR

2 DELKAPITTEL 1 INNLEDNING Kravspesifikasjonen er svært nyttig sett i forhold til produktet vi ønsker å utvikle. Dokumentet regnes som et av de viktigste i hovedprosjektet og forteller oss hva vi skal lage, og hvordan produktet prinsipielt skal fungere. Den tar også for seg noen av komponentene vi kommer til å bruke, samt komponentene vi skal ta utgangspunkt i. Dette dokumentet skal gi alle parter et innsyn i hvordan oppdragsgiver og prosjektgruppen har utdypet oppgavebeskrivelsen, ved å definere hvilke krav som oppgaveløsningen skal oppfylle. Det vil bli utført en analyse av behovet som systemet skal ivareta, og etter å ha lest gjennom dette dokumentet skal man ha skaffet seg en forståelse for behovene vi ønsker å dekke. 1.1 OPPDELING AV KRAV Prosjektgruppen har fastslått å forenkle fremstillingen av kravene i dette dokumentet. På grunnlag av dette har man valgt å dele inn kravene i følgende deler: Rammekrav Funksjonelle krav Use Case modell Designkrav Teknisk krav 1.2 SPORBARHET Kravspesifikasjonen er konstruert med tanke på sporbarhet. Hvert krav har fått tildelt sitt unike krav ID. På denne måten kan lett finne tilbake til kravet på et senere tidspunkt. Tabell gir en illustrasjon av kravtypene som danner grunnlaget for oppbygningen av krav ID. FORKORTEL SE KR KF KA KD KT KRAVTYPE Rammekrav Funksjonelle krav Andre krav Design krav Tekniske krav 2

3 Krav ID-en er bygget opp slik: KTX, hvor K står for krav, T står for kravtype, og X er et tall. 1.3 PRIORITET I dette dokumentet har vi valgt å klassifisere prioriteten på alle krav. Hvert krav har enten høy, middels eller lav prioritet. 3

4 DELKAPITTEL 2 INTRODUKSJON TIL OPPGAVEN Prosjektoppgaven er selve ryggraden til kravspesifikasjonen. På grunnlag av dette er det betydningsfullt å gi leseren en kort introduksjon til selve prosjektoppgaven, slik at man kan se kravene som er beskrevet i dette dokumentet i sammenheng til oppgaven. Derfor vil vi i dette kapittelet gi en kort innføring i selve prosjektoppgaven. 2.1 BAKGRUNN Entobutikk er en privateid og familiedrevet nettbutikk som selger produkter innenfor data, helse og velvære. Bedriften importerer varene direkte fra fabrikker i Asia, spesielt fra Kina. Deres hovedfokus er høy kvalitet produkter med gode priser, og god service til hver enkelt kunde. Per i dag benytter bedriften en eksisterende nettside for å selge produktene sine. Nettsiden er kodet med enkel html-kode. Denne nettsiden viser alle produkter og produktbeskrivelse, men kan bare kjøpe produkter via telefon eller epost. Den mangler enkelte funksjoner og løsninger som kunne ha gjort det bedre for både kunder og administrator, som f. eks innloggingsrutiner, layout, brukervennlighet, handlekurv og historikk. Entobutikk ønsker en bedre og komplett nettbutikk med flere funksjoner for kunder og administrator. 2.3 OM HOVEDPROSJEKTET Prosjektet gjennomføres som hovedprosjekt ved Høgskolen i Oslo, avd. for ingeniørutdanning våren 2010 i samarbeid med Entobutikk. Det skal utvikles en enkel og brukervennlig nettside som er lettere å bruke/lese og oppdatere. Her får kunder mulighet til å se/endre på sin historikk og personlige opplysninger. Administrator skal få kunne oppdatere siden, få oversikt over produkter og kunder uten at vedkommende må kunne programmering. Vi skal finne en mer avansert løsning enn den nåværende, med hensyn på brukervennlighet, sikkerhet, brukergrensesnitt, og med flere funksjoner enn den nåværende nettbutikk tilbyr. 4

5 DELKAPITTEL 3 SYSTEMKRAV Dette kapittelet beskriver krav til systemets oppsett, design, funksjonalitet og utviklingsmiljø vi synes passer best til å utvikle dette systemet. Alle krav til nettbutikken ble utviklet ut fra diskusjonen med oppdragsgiver og ekstern veileder, Kirsten Ribu. 3.1 RAMMEKRAV Det stilles en rekke pålitelighetskrav og lisenskrav til produktet. Derfor har prosjektgruppen valgt å utlede rammekrav, som kan ses i sammenheng med produktet som skal utvikles i løpet av dette prosjektet. Slik ser følgende rammekravene ut: Applikasjonen skal kobles opp mot en Sql server, som også støtter.net. Løsningen skal implementeres i ASP.Net. Det skal være mulig å kjøre løsningen fra skolens server og oppdragsgivers server. Løsningen må kunne hvert fall kjøres i Internet Explorer, Mozilla Firefox, Chrome, Opera og safari. Man skal ikke være avhengig av spesialisert programvare eller maskinvare for å få tilgang til nettbutikken. Alt som kodes i XHTML skal kunne valideres på FUNKSJONELLEKRAV Dette delkapitelet tar for seg de funksjonelle kravene for systemet vi skal utvikle. De funksjonelle kravene er definert som krav som spesifiserer de faktiske funksjonene et system skal utføre. Med andre ord skal det beskrives hvordan systemet skal fungere og hvordan det skal håndtere forskjellige situasjoner. Systemet skal ha tre brukertyper: administrator, kunde og gjest. Slik skal funksjonene deres være: Admin - Skal ha eget grensesnitt som skal være enkel å bruke. Høy - Administrere produkter, kategorier, kunder og bilder. Høy 5

6 - Ha tilgang til ordreliste. Høy - Ha tilgang til ordrehistorikk. Høy - Slette en ordre/kunde. Høy - Ha eget logginnfunksjon samt eget URL. Høy - Liste ut alle produkter og kunder Middels - Ha oversikt over varelageret Middels Kunder - Registrere seg for å bli kunde. Høy - Legge til et eller flere produkter i handlekurven. Høy - Slette produkter fra handlekurven. Høy - Kjøpe produkter ved å betale via PayPal eller faktura. Høy - Endre personlige opplysninger. Høy - Ha egen logginn funksjon. Høy - Når kunde har kjøpt et produkt, skal han få kvittering i epost Middels for betaling. - Se sin egen ordrehistorikk. Middels - Ha tilgang til å se produkter og deres beskrivelse. Høy - Ha tilgang til online chat. Veldig lav Gjester/anonyme - Lese aktuelle nyheter på hovedsiden. Høy - Ha tilgang til å se produkter og deres beskrivelse. Høy - Legge til et eller flere produkter i handlekurven. Høy - Slette produkter fra handlekurven. Høy - Kjøpe produkter ved å betale via PayPal eller faktura. Høy - Trenger ikke å registrere seg. Middels 6

7 Systemet skal også ha andre funksjoner som følgende: Produkter - Registreres, endres og legges inn i database av Admin. Høy - Hvert produkt skal få unik ID(tall). Høy - IDen skal brukes til å legge, slette og endre produktet i Høy databasen. - Alle produkter skal ha minst en kategori. Høy - Retur av produkter skal registreres i databasen. Middels - Hvert produkt som selges skal være mulig å spore opp via Lav posten. - Hvert produkt kan ha maksimum seks bilder. Hvor bildene skal Høy vises med silverlight/flash. - Alle produkter skal inneholde pris, bilde og spesifikasjoner. Høy Kategori - Registreres, endres og legges inn i database av Admin. Høy - Hver kategori skal få unik ID(tall). Høy - Iden skal brukes til å legge, slette og endre kategorien i Høy databasen. - Alle kategorier skal ha minste et produkt. Høy - Alle kategorier trenger ikke ha underkategorier. Middels Handlekurv - Handlekurven skal regne ut total prisen for alle produktene Høy - Frakt skal regnes ut ifra hvor mange/store produkter det er. Høy - Handlekurven skal automatisk kobles til betalingssystem. Middels Søk funksjonen - Vanlig søk: kunde og gjest skal kunne utføre søk ved å skrive søkeord i søkefeltet. - Avansert søk: kunde og gjest skal kunne søke etter produkter i forhold til produktnavn, produktid, kategori og lignende. Høy Lav 7

8 Ordrebekreftelse funksjonen - Systemet skal kunne sende e-post med ordrebekreftelse til kunden etter at betalingen har blitt bekreftet. Høy Bestillingsbekreftelse funksjonen - Systemet skal kunne sende e-post med betalingsbekreftelse til entobutikk etter at betalingen har blitt bekreftet og dataene har blitt sendt til databasen. Høy Kontakt funksjonen - Kunden skal kunne sende elektronisk melding til entobutikk. Lav 3.3 ANDRE KRAV Her lister vi opp de øvrige funksjonene som nettbutikken skal ha: Øvrige funksjoner - Kontrasten mellom tekst og bakgrunn skal være bra, sånn at det Høy ikke skal være vanskelig å lese teksten for døve/blinde. - Fargetemaet på nettsiden skal ikke være for lys eller for mørk. Middels - Skrift: samme font over hele nettbutikken, ikke kursiv Høy - Bakgrunnen skal være hvit Høy - Tittel på nettbutikk skal være i rød skrift etter ønske fra oppdragsgiver. Høy - Tre-klikksregelen skal følges. Man skal aldri måtte klikke mer enn tre Middels ganger for å finne informasjonen man er ute etter. - Alle registreringer og endringer skal registreres i databasen. Høy - Layout til hele nettbutikken kan endres med hensyn på farger. Lav - All kode skal dokumenteres skikkelig for videreutvikling av Middels nettbutikken. - Lage forståelige og lett lesbare instruksjoner. Høy 8

9 3.4 USE CASE DIAGRAM 9

10 3.3.1 USE CASE BEKSRIVELSER Use case - Se produkter Use case Se produkter Aktør Trigger Admin, kunde, gjest Brukeren velger å gå på hjemmesiden entobutikk.no, ønsker å se produktene Pre Post Normal hendelsesflyt Variasjoner Relatert informasjon Brukeren går på nettsiden og ser produkter Fikk sett produktene. Fikk ikke sett produktene. 1. Brukeren taster nettadressen 2. Systemet sjekker om nettadressen eksisterer 3. Nettsiden blir åpnet 4. Brukeren velger kategori og produkter for å se 2. Nettadressen eksisterer ikke 2.a: Systemet informerer brukeren om at nettadressen ikke ble funnet 3. Nettsiden er nede 3.a:Systemet informerer brukeren å prøve igjen senere - Nettadressen må være riktig skrevet. Use case - Se ordrehistorikk Use case Se ordrehistorikk Aktør Admin, kunde Trigger Kunden velger å logge seg inn i hjemmesiden og se ordrehistorikk Pre Post Normal hendelsesflyt Kunden er logget inn og ser ordrehistorikk Fikk se ordrehistorikk Fikk ikke sett ordrehistorikk 1. Systemet ber om brukernavn og passord 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Kunden velger å se ordrehistorikk 4. Systemet returnerer lagret ordrehistorikk Variasjoner Relatert 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Kunden finner ingen ordrehistorikk 3.a:Systemet informerer kunden om at han ikke har noen ordrehistorikk - Dersom det er en eksisterende kunde, må brukernavn og passord være 10

11 informasjon riktig, ellers må kunden registrere seg. Use case Ordreliste Use case Ordreliste Aktør Admin Trigger Admin vil se ordrelisten Pre Post Normal hendelsesflyt Admin ser ordrelisten Får sett ordrelisten Får ikke sett ordrelisten 1. Systemet ber om brukernavn og passord (for admin) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Admin velger å se ordreliste 4. Systemet returnerer lagret ordreliste Variasjoner Relatert informasjon 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin finner ingen ordreliste 3.a:Systemet informerer admin om det ikke finnes noen ordreliste - Nettadressen må være riktig skrevet. Use case - Bestille produkt Use case Aktør Trigger Pre Post Normal hendelsesflyt Bestille produkt Paypal, kunde, gjest Bruker vil bestille produkt Bruker bestiller produkt Får bestilt produkt Får ikke bestilt produkt 1. Bruker velger produkt 2. Systemet sjekker om produktet er på lager 3. Bruker betaler, paypal 4. Systemet registrer ordren 5. Systemet bekrefter registrert ordre Variasjoner 2. Produktet finnes ikke på lager 11

12 Relatert informasjon 2.a: Systemet informerer bruker om å prøve senere eller evt. når varen er på lager 3. Paypal fungerer ikke som den skal 3.a:Systemet informerer bruker om bestillingen ikke ble utført - Må betale online Use case - Redigere produkt Use case Redigere produkt Aktør Admin Trigger Admin vil redigere produkt Pre Post Normal hendelsesflyt Admin redigerer produkt Får redigert produkt Får ikke redigert produkt 1. Systemet ber om brukernavn og passord (for admin) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Admin redigerer produkt 4. Systemet bekrefter redigering av produkt Variasjoner Relatert informasjon 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin får ikke redigert produkt 3.a:Systemet informerer admin om å prøve igjen senere - Admin må være innlogeet Use case - Redigere info Use case Aktør Trigger Pre Post Redigere informasjon Kunde Bruker vil redigere info Bruker redigerer info Får redigert info Får ikke redigert info Normal hendelsesflyt 1. Systemet ber om brukernavn og passord (for 12

13 kunde) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Bruker redigerer info 4. Systemet bekrefter redigering av informasjon Variasjoner Relatert informasjon 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin får ikke redigert informasjon 3.a:Systemet informerer admin om å prøve igjen senere - Bruker må være innlogget Use case - Redigere kunderegister Use case Redigere kundereg. Aktør Admin Trigger Admin vil redigere kunderegister Pre Post Admin redigerer kunderegister Får redigert kundereg. Får ikke redigert kundereg. Normal hendelsesflyt 1. Systemet ber om brukernavn og passord (for admin) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Admin får redigert kunderegister 4. Systemet bekrefter redigering av kunderegister Variasjoner Relatert informasjon 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin får ikke redigert kunderegister 3.a:Systemet informerer admin om å prøve igjen senere - Bruker må være innlogget 13

14 Use case Se kundeliste Use case Se kundeliste Aktør Admin Trigger Admin vil se kundelisten Pre Post Normal hendelsesflyt Variasjoner Relatert informasjon Admin ser kundelisten Får sett kundelisten Får ikke sett kundelisten 1. Systemet ber om brukernavn og passord (for admin) 2. Systemet sjekker om brukernavn og passord eksisterer og om det er riktig 3. Admin får sett kundeliste 4. Systemet sender ut kundelisten 2. Brukernavnet finnes ikke i databasen 2.a: Systemet informerer administrator og går ikke videre før brukernavnet og passord er gyldig 3. Admin får ikke sett kundelisten 3.a:Systemet informerer admin om å prøve igjen senere - Bruker må være innlogget Use case - Betaling Use case Aktør Trigger Pre Post Normal hendelsesflyt Variasjoner Relatert informasjon Betaling Paypal, Kunde, Gjest Bruker betaler bestilt produkt via PayPal Bruker betaler produkt Får betalt produkt Får ikke betalt produkt 1. Bruker godkjenner bestilling 2. Bruker betaler, paypal 3. Systemet registrer ordren 4. Systemet bekrefter registrert ordre 2. Betaling kan ikke gjennomføres 2.a: Systemet informerer bruker om bestillingen ikke ble utført - Betaler online via PayPal ELLER - Få tilsendt faktura 14

15 3.5 DESIGNKRAV Hovedkravet til designet var at løsningen skulle være brukervennlig, enkel å bruke, strukturert. Prosjektgruppen har bestemt å lage masterpage med manylinje øverst på siden, og kategorimeny og søkefunksjonen til venstre siden. Helt øverst har vi tenkt å ha logoen til bedriften og søkfunksjonen helt til høyre på siden. Dette gjør at menyen blir statisk og er en del av grunndesignet som gjør den tilgjengelig uansett hvor man er på nettbutikken. Øverste meny har følgende struktur: - Hjem link som vil føre brukeren til hovedsiden. - Om bedriften link som vil føre brukeren til Om oss siden. - Min konto link som vil føre brukeren til Min konto siden. - Handlekurv link som vil føre brukeren til Handlekurven siden. - Logg inn link som vil føre brukeren til Logg inn siden. - Produkter link som vil føre brukeren til nye produkter siden. - Kontakt oss link som vil føre brukeren til Kontakt oss siden. Søkefelt skal være tilgjengelig uansett hvor man er i løsningen. Det skal være mulig å kunne søke på nøkkelord og finne produkter man leter etter. I tillegg må man ta hensyn til hva som lar seg utføre når man planlegger design. Programmet skal designes på en slik måte at det er fleksibelt og enkelt lar seg bygges videre på. 15

16 Vi har laget ett utkast av designet, som etter hvert vil bli endret: 16

17 DELKAPITTEL 4 TEKNISKE KRAV Utviklingsprogram: Visual Studio 2010, php Expression silverlight, Expression studio 4. Programmeringsspråk: ASP.Net/c#, HTML, CSS. Database: MySQL. Andre programmer: Office pakke, photoshop, paint, Snagit. Gruppen har friheten til å velge selv fremgangsmåten og programmering språket. Valget stod mellom PHP og ASP.Net. Ut fra erfaringene og etter flere diskusjoner i gruppen bestemte vi oss for å velge ASP.Net og MySQL. Vi har tenkt til å bruker vanlig html, ASP.Net/C#, CSS og mysql database for å utvikle systemet. Disse verktøyene gjør det mulig å lage en funksjonell og brukervennlig nettbutikk for brukerne. 17

18 DELKAPITTEL 5 KRAV TIL DOKUMENTASJON I hele prosjektperioden skal det føres en prosjektdokumentasjon som beskriver hva som blir gjort og når de ulike oppgavene blir utført. Vårt ferdige prosjekt skal inneholde følgende dokumenter: - Kravspesifikasjon - Prosessrapport - Produktrapport - Testrapport - Brukerveiledning I tillegg til dette skal dokumentasjonen legges inn i koden i form av velvalgte navn på datafelt, variabler og funksjoner, samt forklarende avsnitt foran de kodeavsnitt som ikke er tilstrekkelig selvforklarende. 18