RUTEPLANLEGGINGSSYSTEM KRAVSPESIFIKASJON

Transkript

1 RUTEPLANLEGGINGSSYSTEM KRAVSPESIFIKASJON Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1

2 CONTENTS 1 Innledning Presentasjon Om bedriften Bakgrunn for prosjektet Veiledning Forord Leserveiledning Beskrivelse av systemet Brukergrupper og funksjonalitet Systemet skal ha følgende brukergrupper: Administratoren skal ha følgende funksjoner tilgjengelig: Regionsjefen skal ha følgende funsksjoner tilgjengelig: Selgeren skal ha følgende funksjoner tilgjengelig: Fremmeren skal ha følgende funksjoner tilgjengelig: Oppdeling av systemet Systemet skal inndeles i følgende hoveddeler: Spesiell funksjonalitet... 7 Ruteplanleggingsdelen skal ha følgende funksjonalitet: Datalagring Rammebetingelser Sikring mot tap, ødeleggelse, tyveri og misbruk av data Risiko Tyveri og misbruk Serverkrav og kapasitet Plattform Nødvendige utvidelser Kapasitet Fremtidig utvidelse av systemet... 8 Side 2

3 4.4 Bruk og brukervennlighet Brukergrensesnitt Begrensning av data som vises Datamodell Krav til datamodell Krav til systemkonstruksjon Programmeringsspråk Programstruktur og lagdeling Variabelnavn Krav til manuelle funksjoner Manuelle funksjoner for brukergruppen regionsjef Manuelle funksjoner for brukergruppen selger Manuelle funksjoner for brukergruppen fremmer Dataordbok Forklaring av brukergrupper Regionsjef Selger Fremmer Side 3

4 1 INNLEDNING 1.1 PRESENTASJON Vår arbeidsgiver, Kraft Foods AS, styrer i dag salgsrutene sine i en tung og avansert løsning basert på Excel-ark. Vår hovedoppgave er derfor å lage en webbasert løsning, som skal erstatte det gamle systemet. 1.2 OM BEDRIFTEN Kraft Foods er en av Nordens ledende næringsmiddelbedrifter med ca ansatte i fire fabrikker. Deres sterke varemerker gjør dem til markedsleder innen kategoriene sjokolade, kaffe, kjeks og andre matvarer. Kraft Foods produserer blant annet varemerkene Freia, Philadelphia og Oboy. 1.3 BAKGRUNN FOR PROSJEKTET Regionssjefene i Kraft Foods benytter seg i dag av en løsning basert på regneark for å organisere selgere, ruter, butikker og kunder. Systemet holder i hovedsak oversikt over hvilke selgere og fremmere som har ansvar for hvilke butikker, og organiserer dagsruter for disse. Systemet brukes også til å lage rapporter av ulike slag. Dagens løsning åpner for mange feil, da de må utføre manuell versjonskontroll. De har også en kundedatabase med ca 4000 kunder som kommuniserer med excel-arkene. Side 4

5 2 VEILEDNING 2.1 FORORD Kravspesifikasjonen definerer krav og betingelser for prosjektet Ruteplanleggingssystem. Mål og problemstillinger er tilpasset Kraft Foods behov, men konkrete løsninger og rammebetingelser er utarbeidet av prosjektgruppen. Dokumentet er en veiledning for utviklerne i prosjektgruppen, slik at systemet blir tilpasset arbeidsgiverens behov. 2.2 LESERVEILEDNING Dette dokumentet er delt opp i hoveddeler som beskriver hva slags egenskaper som skal bestemmes. Underpunkter med mye data er oppdelt i punktlister, og dette definerer krav for hovedfunksjonene i dokumentet. Punkt 3 Beskrivelse av systemet definerer systemets hovedfunksjoner. Side 5

6 3 BESKRIVELSE AV SYSTEMET Ruteplanleggingssystemet skal være ett forenklet alternativ til dagens løsning med excel-ark. Systemet skal tilby samme funksjonalitet som utgangspunktet, men skal samtidig designes på en slik måte at det er enklere i bruk. Der det er mulig skal det brukes dropdown-menyer og auto-søk funksjoner, slik at brukeren ikke trenger å huske kundenummer og andre relevante data. Det skal være enkelt å søke opp informasjonen man trenger, slik at brukeren får en enklere navigering av systemet. Informasjonen som vises må også begrenses, slik at brukeren får færre forstyrrende elementer. 3.1 BRUKERGRUPPER OG FUNKSJONALITET SYSTEMET SKAL HA FØLGENDE BRUKERGRUPPER: Administrator Regionsjef Selger Fremmer ADMINISTRATOREN SKAL HA FØLGENDE FUNKSJONER TILGJENGELIG: Ett grensesnitt for import av data fra AraWin via Exceldokument REGIONSJEFEN SKAL HA FØLGENDE FUNSKSJONER TILGJENGELIG: Oversikt over butikker, selgere og fremmere avgrenset til sin region. Mulighet til å administrere hvilke fremmere som jobber under hvilke selgere. Mulighet til å administrere ruteoversikten for en gitt selger. Det vil si en oversikt over hvilke butikker en gitt selger skal besøke i løpet av en dag. Her vil det være en fordel med muligheten til å veksle mellom dags, ukes og månedsvisning. Etter administratoren har importert ny data, må systemet si ifra om butikker som ikke har tilegnet selgere og fremmere, slik at brukeren enkelt kan holde oversikt over hva som er oppdatert SELGEREN SKAL HA FØLGENDE FUNKSJONER TILGJENGELIG: Mulighet til å se hvilke fremmere som jobber under seg, og kontaktinformasjon for disse. Mulighet til å se hvilke butikker som inngår i selgerens ansvarsområde. Mulighet til å hente ut kontaktinformasjon og addresse for butikkene i sitt ansvarsområde. Mulighet til å se hvilke dagsruter regionsjefen har planlagt. Mulighet til å se en liste over butikker som er spesielle for denne måneden. Såkalte sesongbutikker FREMMEREN SKAL HA FØLGENDE FUNKSJONER TILGJENGELIG: Mulighet til å se oversikt over dagsrutene, og kontaktinformasjon for butikkene som skal besøkes. 3.2 OPPDELING AV SYSTEMET Side 6

7 3.2.1 SYSTEMET SKAL INNDELES I FØLGENDE HOVEDDELER: Butikker Selgere Fremmere Ruter Rapporter 3.3 SPESIELL FUNKSJONALITET RUTEPLANLEGGINGSDELEN SKAL HA FØLGENDE FUNKSJONALITET: Brukeren velger fra en meny hvilken selger han skal planlegge rute for. Etter at selger er valgt, får man opp en timeplan som dekker gjeldende måned. Brukeren kan velge å opprette en ny måned, som legger seg etter gjeldende måned. Måneden som opprettes skal være ferdig planlagt, basert på butikkenes informasjon om ukedager og besøksfrekvens. Hvis brukeren flytter på en oppføring som er autogenerert, skal det gis spørsmål om dette er en permanent endring, eller spesielt for denne måneden. Svarer brukeren at det er permanent, skal butikkinformasjonen oppdateres slik at den autogenereres på riktig sted neste gang. Hvis brukeren ønsker det, skal det kunne vises kun en eller to uker. På butikker som kun skal besøkes i sesong, skal disse komme opp i en egen to-do liste ved siden av de faste rutene. En ruteoppføring består av Butikknavn, Tid i butikk, Eventuell fremmer og fremmerens tid. Hvis det kun er fremmeren som skal besøke butikken denne dagen, vil Tid i butikk bli satt til null, og fremmerens tid til det antallet minutter fremmeren har til rådighet. En ruteoppføring knyttes til en gitt ukedag, og før eller etter lunch. Ingen tidspunkt skal benyttes. Men total tid før og etter lunch bør vises. 3.4 DATALAGRING Bedriften bruker ett datasystem som heter AraWin til å lagre informasjon om kunder, kjeder, grossister, selgere og områdene disse tilhører. Av sikkerhetsmessige årsaker kan ikke webløsningen kobles til denne databasen, og i utgangspunktet har vi kun tilgang på en dump fra AraWin til ett excel-ark. Dette betyr at løsningen som skal utvilkes må ha ett adminpanel hvor databasen kan oppdateres via import fra excel. Systemet vårt skal derfor ikke ha mulighet til å endre kundeinformasjon. Dette må oppdateres av bedriften i AraWin, og deretter importeres til systemet. Men systemet må også ha en egen database for lagring av den importerte dataen, samt all informasjon om rutesystemet. Side 7

8 4 RAMMEBETINGELSER 4.1 SIKRING MOT TAP, ØDELEGGELSE, TYVERI OG MISBRUK AV DATA RISIKO Kraft Foods benytter seg som nevnt av en databaseløsning driftet av ett eksternt firma. Dermed må vi ta utgangspunkt i at disse allerede har gode rutiner for backup av kundedatabasen. Systemet vi lager vil lagre mye informasjon som genereres automatisk ut ifra kundedatabasen deres, derfor innebærer systemet relativt lav konsekvens for tap av data. Når en måned i ruteplanleggeren opprettes, lages rutene automatisk ut ifra data som allerede er lagret, og dette kan enkelt gjøres på nytt. Men allikevel tar dette tid, og det må utarbeides rutiner for backup av serveren som systemet skal kjøres på TYVERI OG MISBRUK Systemet må utvikles på en så sikker måte som mulig. Det må kontrolleres for sql-injection og all input må valideres. I tillegg må det sørges for at excel-dokumentet som importeres har en slags signatur, slik at det ikke er mulig å importere feil data. Brukertilgangen skal også tilpasses etter least-privilege prinsippet, altså at brukerene kun har tilgang til den informasjonen som er høyst nødvendig, og ikke kan endre informasjon som ikke er absolutt nødvendig å endres på. 4.2 SERVERKRAV OG KAPASITET PLATTFORM Serveren må støtte ASP.NET med Microsoft.NET Framework 4.0 og SQL Server Fortrinnsvis en Microsoft server, men det er også mulig å få dette til å fungere under Linux NØDVENDIGE UTVIDELSER For import av Exceldokumenter kreves det ett programtillegg som kan lastes ned fra Microsoft sine websider. Se produktdokumentasjon, punkt 10.3 Nødvendige utvidelser av server, side KAPASITET Systemet vil ikke stille store krav til serverkapasitet. All data som lagres er tekstbasert, og krever derfor ikke stor lagringsplass. Det vil heller aldri bli mange brukere som bruker systemet hardt på en gang, derfor stilles det heller ikke store krav til prosessorkraft og minne på serveren. 4.3 FREMTIDIG UTVIDELSE AV SYSTEMET Oppbygningen av systemet må følge en fornuftig struktur, og bygges med en ryddig lagdeling slik at videreutvikling er mulig. Kraft Foods selv overtar ansvar for videre utvikling og drift av systemet. 4.4 BRUK OG BRUKERVENNLIGHET BRUKERGRENSESNITT Side 8

9 Systemet bør følge retningslinjer for oppbygning av brukergrensesnitt. Herav plassering av knapper og dialoger, slik at brukeren skal få færrest mulig forstyrrende elementer, uten å miste funksjonalitet. Det skal også brukes hjelpefunksjoner som drop-down menyer, autofullfør, smarte søk og andre relevante hjelpemidler BEGRENSNING AV DATA SOM VISES Dagens løsning gir ekstremt mye data til brukeren på en gang. Dette ønsker Kraft Foods at vi klarer å begrense, slik at kun nødvendig informasjon vises til brukeren. I tillegg skal kun relevant data være mulig å endre på. Dagens løsning har åpne felter slik at det enkelt kan gjøres endringer som ikke skulle vært gjort. Side 9

10 5 DATAMODELL 5.5 KRAV TIL DATAMODELL Datamodellen må oppfylle 3. normalform. Side 10

11 6 KRAV TIL SYSTEMKONSTRUKSJON 6.1 PROGRAMMERINGSSPRÅK Systemet skal programmeres i ASP.NET og C# 6.2 PROGRAMSTRUKTUR OG LAGDELING Programmet skal struktureres på en ryddig og oversiktelig måte, og følge ett lagdelingsprinsipp som gjør videreutvikling og oversikt enklest mulig. 6.3 VARIABELNAVN Variabelnavn skal være beskrivende, og inneholde referanse til objektet det er en variabel av. Er det en label skal variabelen ha navn labelkundenummer eller lignende. Side 11

12 7 KRAV TIL MANUELLE FUNKSJONER 7.1 MANUELLE FUNKSJONER FOR BRUKERGRUPPEN REGIONSJEF Mulighet til å ta utskrift av alle rapporter som er tilgjengelig gjennom systemets rapportgenerator. Mulighet til å ta utksrift av alle dagsruter. Mulighet til å ta utskrift av kontaktinformasjon for selgere og fremmere. 7.2 MANUELLE FUNKSJONER FOR BRUKERGRUPPEN SELGER Mulighet til å skrive ut sin aktuelle dagsrute. Mulighet til å skrive ut kontaktinformasjon om kunden som skal besøkes. Mulighet til å skrive ut kontaktinformasjon om fremmere som arbeider under seg. 7.3 MANUELLE FUNKSJONER FOR BRUKERGRUPPEN FREMMER Mulighet til å skrive ut sin aktuelle dagsrute. Mulighet til å skrive ut kontaktinformasjon om kunden skal besøkes. Mulighet til å skrive ut kontaktinformasjon om selgeren som er vedkommendes overordnede. Side 12

13 8 DATAORDBOK 8.1 FORKLARING AV BRUKERGRUPPER REGIONSJEF Personen som i utgangspunktet styrer hele systemet. Regionsjefen er den eneste av de tre vanlige brukerne som skal ha mulighet til å endre data på ruteplanleggingsdelen SELGER Selgeren er regionsjefens produktpromotør i ett gitt geografisk område. I systemet har han kun mulighet til å se hvilke dagsruter regionsjefen har satt opp for selgeren og de fremmere som jobber under selgeren FREMMER Fremmerens oppgave er å fylle på varer i butikkene. I systemet skal han bare se sin egen dagsrute og kontaktinformasjon til selgeren han jobber for. Side 13