PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00 Telefaks: 22 45 32 05 PROSESSDOKUMENTASJON HOVEDPROSJEKTETS TITTEL: Dekklåven DATO: 31. mai 2008 ANTALL SIDER / BILAG: PROSJEKTDELTAKERE: Chau Quoc Do, Einar Drivdal, Nikolai Godager og Kevin Holmvik INTERN VEILEDER: Steinar Johannessen OPPDRAGSGIVER: Dekklåven KONTAKTPERSONER: Dag Terje Bjørlo tlf: 62 35 50 20 SAMMENDRAG I kravspesifikasjonen vil det være en oversikt over hva vi har planer om å gjøre i prosjekt perioden, dokumentet er en detaljert plan over hva som må gjøres for å kunne sette sammen et produkt ved prosjekt slutt. Tittelside STIKKORD: Systemkrav, Design, Dokumentasjon
Forord Denne kravspesifikasjonen beskriver betingelsene for prosjektet Dekklåven. Den forteller funksjonaliteten og rammebetingelsen. Dekklåven har selv bestemt funksjonaliteten, mens resten har gruppen selv bestemt om hvordan produktet skal bli. 1 Innledning Prosjektet skal gjennomføres som hovedprosjekt ved Høgskolen i Oslo, avdeling for dataingeniør i samarbeid med Dekklåven AS. Oppgaven består av å utvikle en webshop, reservasjonsbestilling og dekkhotell med et grensesnitt som de ansatte har mulig til å administrere. For å utvikle dette systemet, har vi tenkt å bruke blant annet Microsoft Visual Studio 2008 og Qt Creator. 1.1 OM BEDRIFTEN Dekklåven AS norskdrivende bedrift som leverer tjenester innenfor salg av dekk og felger, utfører dekkskift og lagring av dekk. Dekklåven AS ble etablert i Brummundal i 2002, og har i dag flere verksteder omkring Oslo området. I dag selger bedriften dekk og felger med importert fra Asia, og utgjør bare dekkskift for kundene. 1.2 BAKGRUNN FOR PROSJEKTET Dekklåven AS har i dag bare kjøp av dekk og felger ved lageret sitt, og dette krever ganske stor kapasitet av ansatte og mye manuelt arbeid. Ved lagring av dekk, har de i dag oppbevart informasjonen i et Excel-dokument og noe som gjør det lite fleksibelt. Håndtering av servicetimer, har de i dag måtte la kundene møte opp og la dem vente til det er ledig time.
2. Systemkrav 2.1 FUNKSJONELLE KRAV Før vi kan begynne å starte med den tekniske biten for prosjektoppgaven, er det greit å ha en oversikt over de kravene som har blitt lagt frem av oppdragsgiveren og av oss selv. Derfor har laget et oversiktlig funksjonelt krav for prosjektoppgaven. 2.1.1 KRAV TIL NETTBUTIKK Nettbutikken skal være direkte knyttet opp imot bedriftens økonomisystem Visma Global. Når bryteren Publiser på nett aktiveres I Global skal artikkelen automatisk publiseres på nettbutikken. Bildene som ligger som artikkelvedlegg I Visma skal legges ut som enhetsbilde på netbutikken. Det skal være mulig å lagre en annen prisprofil på nett en den som er standard butikkpris ved lokalkjøp I Visma. Nettbutikken skal ikke vise nøyaktig lagerstatus slik som økonomisystemet gjør, men begrense det til: o Tomt, forventet på lager: XXDatoXX, o Færre enn 10, o Flere enn 10, o Flere enn 100 Det skal være mulig å handle med kredittkort 2.1.2 KRAV TIL RESERVASJONSSYSTEM Kunden skal ha muligheten til å reservere timer hos verkstedet. Systemet skal kunne oppdateres snarest en reservasjon har blitt opprettet, for å unngå dobbelbooking. For at kunden skal ha muligheten for å opprette en reservasjon, må kunden selv være pålogget.
2.1.3 KRAV TIL DEKKHOTELL Det skal være mulig å lagre og endre på følgende: Navn på de forskjellige lagere Informasjon om lagringsplasser for hvert lager Navn og telefonnummer på kunder Informasjon om hvor dekkene til en kunde ligger lagret Brukeren av systemet skal kunne: Utføre oppgavene som står skrevet over Søke på navn, etternavn eller telefonnr. for å finne ut hvor dekkene til en kunde er lagret Søke på lagernummer eller plassnummer for å finne ut hvem som har dekkene sine lagret hvor 2.1.4 KRAV TIL ADMINISTRATORSYSTEM Det var ønskelig å få en applikasjon som gjør det mulig for bedriften å reservere timer ihht. hvilken tidsinndelinger de benytter. Applikasjonen skal kunne brukes av flere klienter lokalt. Etter dialog med bedriften ble det stilt følgende krav til applikasjonen: Oppdatering imellom klienter skal foregå i realtime Klient B skal ikke kunne overskrive en post som klient A har åpen Det skal være mulig å endre tidsintervallene på inndelingene. Det skal være ulike brukergrupper med tilhørende forskjellige rettigheter Applikasjonen skal kunne jobbe opp imot en et timebestillingssystem som skal integreres mot deres hjemmeside. Applikasjonen skal kunne brukes til å presentere historiske og fremtidige poster på storskjerm ved kundemottaket.
2.1.5 TEKNISKE KRAV Utvikles i MS Visual Studio 2008 med C# som programmeringsspråk. Utvikles i Qt Creator med C++ som programmeringsspråk. Lagring av database skal skje i SQL Server Management Studio Express. Applikasjonen skal kunne kjøres på en Windows Server. Nettsiden skal være utviklet ved følgende programmeringsspråk: HTML, CSS og Javascript.
3 Datalagring For å håndtere datalagring meste mulig fornuftig, har lagt frem noen krav som vi alle i gruppen har noen å tenke mens vi utvikler programmet. All data skal være skjult for andre, bare de ansatte skal ha muligheten til å se data. Database til systemet skal være normalisert. 3.1 DESIGN Sidene skal være mest mulig brukervennlig, oversiktlig, behagelig, profesjonelle og ryddige. For å kunne bruke siden, skal det ikke kreves noen krav fra brukerne for å kunne bruke siden. For å navigere gjennom siden, skal brukeren mest mulig komme dit ved få museklikk, og med dette gjelder det for både kundesiden og administrator siden. Siden skal være selvforklarende og enkle navigeringssystem slik at brukeren skal aldri tvile på hva han gjør. 3.2 BRUKEGRENSESNITTET Applikasjonene bør være så enkel og intuitiv å bruke som mulig. Det er ønskelig at en person uten videre IT-kunnskap skal kunne sette seg ned og bruke det uten problemer. Samtidig er det ikke ønskelig at dette skal gå ut over programmets funksjonalitet. 3.3 KODE KRAV Koden skal være oversiktelig og følge samme standard. Det skal gå frem av navnet til en metode og en variabel hva denne gjør/inneholder. For eksempel vil en metode som sletter en kunde fra databasen gjerne kalles "fjernkunde" eller "slettkunde" i stedet for noe mer kryptisk som "metode5". Koden skal også kommenteres flittig. Helst skal enhver metode og variable forklares v.h.a. kommentarer. Dette er for å gjøre jobben enklere for en vedlikeholder eller en eventuell videreutvikler av programmet.
3.4 KRAV TIL DOKUMENTASJON Det ferdige dokumentet skal beskrive alt som er blitt gjort gjennom denne prosjekt perioden. Det ferdige dokumentet skal bestå av: - Kravspesifikasjon, definering av kravene til systemet. - Prosessrapport, beskriver arbeidet i de forskjellige fasene. - Produktrapport, beskriver systemet. - Testrapport, tester som har blitt utført og resultatet. - Brukerdokumentasjon, brukerveiledning. Under prosjektoppgaven, synes vi at en dagbok er et verktøy som kan bli nyttig å bruke ved seinere tid. Derfor har vi bestemt oss for å skrive dagbok så ofte vi kan, helst hver eneste gang vi jobber sammen. 3.5 VIDEREUTVIKLING Hele systemet skal være programmert på en strukturert måte for fremtidlige videreutvikling. For å få systemet til å være lettere videreutvikling, skal vi kommentere mest mulig av kildekoden og et dokument som er godt bygg opp for de andre enn oss som skal videreutvikle.