KRAVSPESIFIKASJON 1
1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter oppdragsgivers behov og ønsker. Den lar oppdragsgiver og gruppen ha en forståelse over de betingelser og krav som er satt til prosjektet 2. Leserveiledning Kravspesifikasjonen starter med en presentasjon av de forskjellige aktørene i prosjektet før den gir en overordnet beskrivelse av systemet. Deretter gis de funksjonelle kravene etter fulgt av ikke-funksjonelle og litt om endringshåndtering. 2
Innholdsfortegnelse 1. FORORD... 2 2. LESERVEILEDNING... 2 3. PRESENTASJON... 4 3.1 GRUPPEN... 4 3.2 OPPDRAGSGIVER... 4 3.3 OM OPPGAVEN... 4 3.4 VEILEDER OG INSTITUSJON... 4 4. OVERORDNET SYSTEMBESKRIVELSE... 4 NETTBUTIKKEN... 4 ADMINISTRASJONSSIDEN... 5 4.1 MÅL NETTBUTIKK... 5 4.2 MÅL ADMINISTRASJONSSIDE... 5 5. FUNKSJONELLE KRAV... 6 5.1 PRIORITERT FUNKSJONALITET... 6 5.2 ØNSKET FUNKSJONALITET... 6 5.3 EVENTUELL TILLEGGSFUNKSJONALITET... 6 6. IKKE - FUNKSJONELLE KRAV... 7 6.1 PRODUKTKRAV... 7 6.1.1 Brukervennlighet... 7 6.1.2 Effektivitetskrav... 7 6.1.3 Pålitelighetskrav... 7 6.1.4 Estetiske krav... 7 6.1.5 Rammekrav... 7 6.2 PROSESSKRAV... 7 6.2.1 Utviklingsmetodikk... 7 6.2.2 Leveransekrav... 8 6.2.3 Implementasjonskrav... 8 7. ENDRINGSHÅNDTERING... 9 7.1 HVEM KAN FORESLÅ ENDRINGER?... 9 7.2 HVORDAN FÅ GJENNOM EN ENDRING?... 9 7.3 FEILHÅNDTERING... 9 3
3. Presentasjon 3.1 Gruppen Gruppen vår består av Ranbir Singh, Giancarlo Morales og Fredrik Tandberg Nilsen. Alle tre går på linjen Anvendt datateknologi ved Høgskolen i Oslo og Akershus. Vi har jobbet sammen i gruppe siden første semester og har fått gode resultater tidligere. 3.2 Oppdragsgiver Oppdragsgiveren er Madison Møbler v/ Thomas Andler, som er et enkeltmannsforetak som driver med import og salg av møbler. Eier og eneste ansatte er Thomas Andler. Så langt har bedriften kun drevet med salg over telefon og finn.no da kompetansen for å drifte en nettside og opplæringen til dette ikke har vært tilstede. 3.3 Om Oppgaven Oppdragsgiver ønsket hjelp til eksisterende løsning som var en ferdigløsning nettside og ikke nettbutikk, med forholdsvis tekniske krav til den som skal vedlikeholde og oppdatere. Da bruker ikke hadde disse kunnskapene så kom gruppe og oppdragsgiver frem til at dette var noe som var ønsket og som vi kunne utvikle. Produktet vil da i motsetning av et ferdigsystem passe vår oppdragsgiver bedre. Dette vil si at systemet har en hensikt at en bruker med reduserte IT kunnskaper skal kunne drive med den daglige driften av nettsiden uten store problemer, slik at arbeidet går effektivt. 3.4 Veileder og institusjon Veileder for prosjektet er Andrè Lincoln Read. Prosjektet fungerer som hovedprosjekt ved Høgskolen i Oslo og Akershus, institutt for informasjonsteknologi. 4. Overordnet systembeskrivelse Systemet skal i utgangspunktet dekke oppdragsgivers behov for en nettbutikk hvor han kan publisere møblene sine, men da oppdragsgivers kunnskaper rundt nettsidekonstruksjon osv. er reduserte så er det behov for en brukervennlig CMS system. NETTBUTIKKEN Systemet vårt er da denne nettbutikken hvor kunder kan se på varene til firmaet og opprette konto for så og gjøre en handel. I tillegg kunne se status på ordre som er gjort. Varer, kategorier og informasjon om dette hentes fra databasen og vises på bestemte steder i nettbutikken. Det skal også være privat- og bedriftskunder hvor brukere kan velge slik at de får priser med eller uten moms. 4
ADMINISTRASJONSSIDEN Administrasjonssiden vil være den største delen av systemet. Her skal oppdragsgiver få mulighet til å styre nettbutikkens innhold ved å justere varelager, legge til nye varer/kategorier, fjerne/endre varer/kategorier. All informasjonen som endres i administrasjonssiden endres i databasen. Nettbutikken henter informasjon om varer og kategorier fra databasen. Videre så skal administrasjonssiden gi bruker mulighet til å se de ordre som er gjort slik at han kan oppdatere status på disse til for eksempel sendt, fakturert og sendt osv. Han skal ha mulighet til å liste varer og kategorier for å kunne legge til, endre eller fjerne. Det skal være mulig å administrere brukere slik at man kan liste opp de som er lagt til eller legge til nye brukere. 4.1 Mål nettbutikk Lage en nettbutikk hvor oppdragsgiver får publisert og gitt nok informasjon om sine produkter. At nettbutikken ser profesjonell ut og frister flest mulig kunder til å kjøpe varer fra nettsiden. Brukervennlig nettside som kun gir nødvendige funksjoner som brukere vil har bruk for. 4.2 Mål administrasjonsside Lage en administrasjonsside som lar bruker administrere innhold i nettbutikk og behandle ordre/brukere/varer. Gi mulighet til å drive en butikk gjennom systemet og gi mest mulig tilbakemelding til kunder. Brukervennlig side som gir bruker minst mulig utfordringer. Få og enkle iterasjoner før en oppgave utføres, slik at arbeidet blir gjort effektivt. 5
5. Funksjonelle krav Funksjonelle krav definerer hva systemet skal gjøre. Det er delt opp i prioritert funksjonalitet (det systemet SKAL gjøre), ønsket funksjonalitet (det systemet BØR gjøre) og eventuell tilleggsfunksjonalitet (det systemet KAN eventuelt skal gjøre om det er tid). 5.1 Prioritert funksjonalitet Systemet skal kunne: Legge ut nye varer som vises med den informasjonen bruker skriver inn ferdig oppsatt på nettsiden. Navn, Kort beskrivelse, lang beskrivelse, kategori, pris eksl. mva. Legge ut ny hovedkategori og underkategori ved å legge til navn og ved underkategori velge under hvilket hovedkategori. Endre eksisterende varer/kategorier slik at informasjon lagret i databasen oppdateres og informasjonen da vist også endres. La oppdragsgiver logge seg inn på administrasjonssiden. La oppdragsgiver kunne fullførte ordre og bestillinger og gi statusoppdatering på disse. La kunder av nettbutikken opprette brukerkonto og fylle inn informasjon samt. om de er privat eller bedriftskunde. La kunder legge ønskede varer i handlekurv. La kunder av nettbutikken gjennomføre en bestilling. 5.2 Ønsket funksjonalitet Systemet bør kunne: Administrere og liste brukere for å endre eller legge til brukere. Både privat og bedrift. La brukere liste sine ordre og se status på disse. Velge bedrift eller privat i nettbutikken for priser med og uten moms. Ha paypal som en betalingsmulighet ved siden av faktura som finnes i dag. 5.3 Eventuell tilleggsfunksjonalitet Systemet kan eventuelt kunne: Ha videoinstruksjoner som forklarer ulike funksjoner tilgjengelig på administrasjonssiden La kunder endre kontoinformasjon Vise salgsrapporter som gir mulighet til å se statistikk av salg osv. Ha en FAQ side som gir bruker mulighet til å se oversikt over kjente problemer tilgjengelig på administrasjonssiden. Gi bruker mulighet til å lese/sende epost direkte fra administrasjonsside. 6
6. Ikke - funksjonelle krav Ikke-funksjonelle krav er ved hvilket rammer systemet skal implementere de funksjonelle kravene. Her delt opp i produktkrav, prosesskrav og eksterne krav. 6.1 Produktkrav Produktkrav er krav til produktet som utvikles. Her er det krav til brukervennlighet, effektivitet, pålitelighet og estetikk. 6.1.1 Brukervennlighet Språk på nettsidene skal være på norsk bokmål. Språk skal være bruke minst mulig fremmedord og fagspråk Bruker skal kunne bruke systemet etter en kort innføring eller ved at bruker selv setter seg inn i systemet.. 6.1.2 Effektivitetskrav Alle nettlesere bør kunne laste siden innen normal hastighet (6 sek) Funksjoner skal kunne gjennomføres uten brems fra systemet. 6.1.3 Pålitelighetskrav Alle data skal lagres trygt i en database og bli her til de fjernes av bruker. Nettbutikken skal alltid være tilgjengelig. Priser og annen informasjon skal oppdateres med en gang bruker har gjort en endring. 6.1.4 Estetiske krav Nettbutikk og administrasjonsside skal i hovedsak bruke symboler sammen med tekst for lettere forståelse. Lite fargekontraster. Bruke de samme fargene gjennom systemet. Oppsett skal være slik at det er lett å finne frem, med lett forklarende ikoner (handlevogn bilde som fører til handlevogn og lignende). Bilder av varer prioriteres foran tekst 6.1.5 Rammekrav Skal lages for alle nettlesere på alle enheter (PC, Mac, Mobil, Nettbrett osv.) og skal skaleres etter skjermstørrelse. Skal brukes HTML, PHP, CSS, MySql, Javascript, Ajax som eget skrevet programmeringsspråk. Bootstrap brukes som template/ferdigdesignet rammerverk som personlig gjøres etter behov. 6.2 Prosesskrav Prosesskrav er krav til prosessen rundt utviklingen av systemet. Det vil si ting som krav til utviklingsmetodikk, leveranse og implementasjon. 6.2.1 Utviklingsmetodikk Fossefall brukes som utviklingsmetodikk 7
6.2.2 Leveransekrav Kravet er likt det skolen har satt som endelig frist for prosjektinnlevering. 6.2.2.1 Endelig levereranse Nettstedene skal være lagt på oppdragsgivers domene og fungere. Skal kunne kjøres fra valgfri enhet med nettilgang og en nettleser. 6.2.3 Implementasjonskrav Produktet skal utvikles for siste versjon Internet Explorer, Mozilla Firefox, Opera, Safari, Google Chrome og andre nettlesere. Produktet skal utvikles for alle oppløsninger. Det vil si PC/Mac i alle størrelser, mobiler og nettbrett. Produktet skal bruke webprogrammering i PHP HTML/CSS rammeverk. MySQL brukes som språk mot databaser Javascript/ajax støtte til andre funksjoner i blant annet bootstrap. 8
7. Endringshåndtering Her tas det for seg hvem som har mulighet til å foreslå endringer og hvordan en endring kan slå gjennom. 7.1 Hvem kan foreslå endringer? Endringer kan bli gjort av interessenter. I dette tilfellet så er det Thomas Andler som er kunde, oppdragsgiver og eneste person i foretaket Madison Møbler. Han kan komme med forslag til endringer der han føler at noe kunne vært annerledes. Gruppen er en annen som kan komme med forslag til endringer. Dette er der de føler at en endring ville vært foretrukket. 7.2 Hvordan få gjennom en endring? Alle interessenter må være enige om en endring (oppdragsgiver, gruppe). Hvis en endring er drøftet og bestemt av gruppen, så skal dette bli tatt videre til oppdragsgiver som godkjenner. Endringen skal ikke skape problemer tidsmessig slik at en endring vil utsette siste frist for fullført system. Må være gjennomførbart. Endringene må vurderes og godkjennes av alle interessenter om de endrer krav som er satt i funksjonelle og ikke-funksjonelle krav. Nye krav må da settes. 7.3 Feilhåndtering Om det er feil på systemets funksjoner eller bruk så må dette rettes før en ny funksjon/prosess påbegynnes eller en funksjon under der feilen er må avbrytes. Dette er for å forhindre skade på eksisterende eller ny kode som mulig ikke vil fungere da en feil er rettet. 9