Intelligente Handlevogner

Transkript

1 Intelligente Handlevogner Kravspesifikasjon Prosjekt I Systemutvikling ved Høgskolen I Gjøvik våren Audun Klundby Asbjørn Konstad Hans Einar Øverjordet 03HBINDA Kilde:

2 1. Introduksjon Bakgrunn Kort om krav til systemet Kort om systemets omgivelser Brukerbeskrivelse Omgivelser Systemets brukere Funksjon Detaljert Kravspesifikasjon Funksjonell kravspesifikasjon Funksjonell struktur og tverr-relasjoner Overordnede operasjonelle krav Funksjonelle krav Begrensninger Software design begrensninger Hardware design begrensninger Aspekter omkring livssyklus Dokumentasjon Krav til support, service og vedlikehold Aspekter omkring installasjon Hardware installasjon Opplæring Side 2 av

3 1. Introduksjon 1.1 Bakgrunn Bakgrunn for prosjektet er henvendelse fra JEMA100 og tilslag på tilbud om utvikling av nytt system for dagligvarehandel. JEMA100 er en dagligvarekjede med 233 butikker på landsbasis. De ønsker å effektivisere måten deres kunder handler i butikkene ved hjelp av et nytt system. 1.2 Kort om krav til systemet JEMA100 ønsker, ved å ta i bruk moderne teknologi, å forenkle og optimalisere prosessen deres kunder har med å handle matvarer/dagligvarer. Målet for prosjektet er å utvikle og implementere systemet for Intelligente Handlevogner (IHID). Systemet skal ivareta brukernes/kundenes spesifiserte krav. JEMA100 ønsker med dette å effektivisere driften gjennom å kutte ned på bemanningen og minke tiden kundene bruker ved de tradisjonelle kassene. Systemet skal også effektivisere tiden kundene bruker i butikken og øke kundegjennomstrømningen med 20 %. Dette vi på sikt øke kjedens omsetning med 35 %. Overordnet mål er i løpet av 6 mnd. etter idriftsettelse av systemet å kunne nedbemanne kassene med 60 %. Systemet skal kunne hjelpe kundene med å gi relevant informasjon om varenes plassering, pris, næringsinnhold samt middagstips og lignende. Det skal også være vis-veg funksjonalitet i løsningen for å hjelpe kundene med å finne en vare, og effektivt kunne utføre handleruten i butikken basert på raskeste-veg. 1.3 Kort om systemets omgivelser IHID utvikles for internt bruk i JEMA100's dagligvarebutikker og er således spesialtilpasset kjedens forretnings-prosesser og strategier, samt kjedens/filialenes fysiske/geografiske utforming. 2. Brukerbeskrivelse 2.1 Omgivelser Systemet skal kunne håndtere alle kundene som er inne i butikken til en hver tid, det vil si opptil 500. Dette vil være standardkonfigurasjonen, men systemet skal kunne skaleres ved oppgradering av hardware. 2.2 Systemets brukere IHID utvikles primært for butikkunder. Dette er en brukergruppe som vil være svært variert mtp. alder og bakgrunn. Det vil derfor være en utfordring for prosjektet å designe systemet så det er i stand til å tiltale så stor grad av bruker-målgruppen som mulig. Dette vil stille spesielle krav til oppbygging av systemet spesielt med tanke på brukergrensesnitt og robusthet i selve applikasjonen. Det settes krav til at systemet må designes så lettfattelig som mulig, men prosjektet vurderer det til at for visse deler av brukergruppen vil være behov for opplæring/støttefunksjon. 2.3 Funksjon Overordnet systemmodell og beskrivelse av hovedmoduler er vist i designdokument. Side 3 av

4 3. Detaljert Kravspesifikasjon 3.1 Funksjonell kravspesifikasjon De funksjonelle kravene i systemet representert ved UseCase med tilhørende beskrivelser som vist i vedlegg 1 og Funksjonell struktur og tverr-relasjoner Funksjonell struktur og tverr-relasjoner er vist ved konseptuelt klassediagram beskrevet i vedlegg Overordnede operasjonelle krav Ytelse I generelle GUI-operasjoner i systemet settes det krav om at responstiden skal være < 0.5 s. Krav til responstid for registrering av sonebytte på en handlevogn skal være < 1s Oppstart og nedtaking Konsollen på handlevognen skal ha en oppstartstid på under 5 sekunder Tilgjengelighet Det stilles krav til 99% oppetid på systemets servere. Vedlikehold og oppdateringer skal skje i et angitt tidsintervall utenfor butikkenes åpningstider. Oppetiden til handlevognkonsollen er ikke så kritisk, men den skal operere slik at det ikke skaper problemer for kundene. Side 4 av

5 3.4 Funksjonelle krav Prosjektet foretok en analyse og risikovurdering av de forskjellige UseCasene, og de funksjonelle kravene er utarbeidet etter de 4 mest kritiske modulene Vise Rute Denne er valgt fordi det er en veldig kritisk del av systemet, dette er den delen av systemet som brukeren ser mye til og det er viktig at den blir riktig implementert. I tillegg er dette en sammensatt enhet som kommuniserer med mange andre komponenter Oppdater Posisjon Dette er også en veldig viktig del av systemet, mange komponenter bruker informasjonen herifra. Det er viktig med en god beskrivelse her siden det er ut i fra dette at det velges hardware til posisjonssystemet Vise Info Denne er valgt fordi det trenger en nærmere beskrivelse for hvordan man velger hvilken info/reklame som skal vises. I tillegg er det viktig at dette blir brukervennlig og ikke kommer i veien for bruken av resten av systemet Registrere varer Denne er valgt fordi det trengs en god beskrivelse for hvordan data skal utveksles med det eksisterende kassa- betalingssystemet. I tillegg er det ikke klare grenser for hva denne skal gjøre ut i fra beskrivelsen. Det er viktig for implementeringen at det er grundig beskrevet hva som skal med og hva som skal håndteres av utenforstående systemer. Side 5 av

6 3.4.5 Detaljert UseCase-beskrivelser UseCase: Aktør: Formål: Sammendrag: Type: Pre: Post: Spesielle krav: Vise Rute Kunde Viser aktøren den mest effektive handlerute gjennom butikken Modulen skal hjelpe aktøren med å finne mest effektive handleruten i butikken. Systemet skal beregne ruten ut fra hvilke varer aktøren har registrert i handleliste og hvor disse er plassert i forhold til hverandre. Modulen skal også kunne benyttes ved at aktøren benytter Finne Varer modulen og ber om veibeskrivelse. Systemet skal representere rute i form av et kart som viser butikklokalet med mest effektive sonerute. I tillegg skal systemet markere plasseringen av de individuelle varene i hver sone. Etter hvert som kunden plukker varen fra hylle og markerer den som registrert, eller eventuelt fjerner varen fra handlelisten, skal systemet fortløpende oppdatere kartet. Etter hvert som kunden beveger seg gjennom ruten skal systemet oppdatere handlevognens posisjon. Dersom kunden avviker fra beregnet rute vil systemet beregne ny rute ut i fra kundens nåværende posisjon. Essensiell Det finnes en rute å vise, enten har aktøren en handleliste eller bruker Finne Varer. Vognen befinner seg i gyldig sone. Ny rute er beregnet og presentert for brukeren Aktør 1. UseCaset starter ved at aktør initierer funksjonen Vise Rute. 5. Aktør plukker varer og krysser av på handleliste etter hvert som ruten tilbakelegges. HENDELSESFLYT Systemrespons 2. Systemet sjekker innhold i handleliste. 3. Systemet finner alle varene i handlelistens sone og hylleplassering, og beregner korteste og mest effektive rute gjennom butikken. 4. Systemet presenterer ruten for aktøren. 6. Systemet oppdaterer ruten fortløpende ettersom handlelisten endres. ALTERNATIV HENDELSESFLYT Punkt 3. Om rute ikke kan beregnes på grunn av ukjent plassering av handlevogn eller vare får brukeren beskjed om dette og får tilbud om å tilkalle hjelp. Side 6 av

7 UseCase: Aktør: Formål: Sammendrag: Type: Pre: Post: Spesielle krav: Oppdater Posisjon Posisjonssystem Holder oversikt over handlevogns posisjon i butikken. Posisjonssystemet skal holde orden på alle aktive handlevogners posisjon i butikken. Når en handlevogn kommer inn i en sone registreres dette via sensorer plassert ved alle innganger til aktuell sone. Posisjonssystemet skal oppdatere IHID med denne informasjonen om hver enkelt handlevogn ved alle sonebytter som finner sted til en hver tid. Essensiell Systemet kjenner til vognenes ID Systemet har ny sone til vognen Det er krav om at posisjonssystemet må oppdatere posisjonen på en handlevogn min. 1 sekund etter at vognen kommer inn i ny sone. HENDELSESFLYT Aktør Systemrespons 1. UseCaset starter ved at en kunde m/handlevogn kommer inn i en sone. 2. Posisjonssystemet registrerer at en handlevogn har kommet inn i sonen 3. Posisjonssystemet sender informasjon til IHID om sone og handlevognidentifikasjon. 4. IHID oppdaterer informasjonen om den aktuelle handlevognen. ALTERNATIV HENDELSESFLYT Punkt 3. Om data ikke gjenkjennes av IHID blir det sendt en feilmelding tilbake til aktøren. Aktøren sender da info en gang til. Om det igjen ikke blir gjenkjent forkastes dataen. Punkt 2. Om man ikke merker at en vogn kommer inn i ny sone, blir sonen oppdatert ved neste sonebytte. Side 7 av

8 UseCase: Aktør: Formål: Sammendrag: Type: Pre: Post: Spesielle krav: Vise Info Kunde Systemet viser kunde/varespesifikk informasjon eller reklame. Ettersom aktøren beveger seg rund i de forskjellige sonene i butikken, skal systemet vise relevant informasjon eller reklame. Systemet skal beregne og velge riktig reklame ut i fra analyse av aktørens profil og handlevaner. Systemet skal også kunne vise reklame på bakgrunn av spesielle tilbud på varer i den aktuelle sonen. Det beregnes en prioritet på reklamene/informasjonen som angir visningsrekkefølgen. Essensiell Aktør beveger handlevogn inn i ny sone. Systemet har vist aktøren relevant informasjon/reklame for sonen. Aktør 1. UseCaset starter ved at aktør beveger seg inn i ny sone. HENDELSESFLYT Systemrespons 2. Systemet beregner handlevognens posisjon og presenterer info/reklame på bakgrunn av beregnede kriterier. Kriterier for visning er innhold i handleliste og aktørens handlevaner. Handlevaner hentes ved hjelp av aktørs profil. 3. Etter endt reklamesnutt fortsetter visning etter angitt prioritet. ALTERNATIV HENDELSESFLYT Punkt 2. Aktør velger å avbryte visning. Systemet stopper fremvisningen av reklamen/informasjonen. Side 8 av

9 UseCase: Aktør: Formål: Sammendrag: Type: Pre: Post: Spesielle krav: Registrere varer Kassasystem Registrere varer for betaling Modulen håndterer betalingsprosessen i IHID. Når kunden kommer inn i betalingssonen varene på blir scannet av betalingssystemet. Modulen benytter eksisterende teknologi i kassesystem for scanningen av varene. Kassesystemet står for betalingsprosessen og er kun integrert med IHID ved at vellykket transaksjon initierer denne modulen i IHID som igjen registrere og lagrer sesjonen i kunden/brukerens profil. Modulen mottar melding fra kassesystem i form av XML med alle varer som er betalt samt beløpsinformasjon som total, mva, evt. rabatter. Essensiell Kunde har beveget handlevogn inn i betalingssone. Aktør har sendt vare og betalingsinformasjon til systemet. Handlevogn må være registrert i betalingssone. HENDELSESFLYT Aktør Systemrespons 1. UseCaset begynner ved at aktøren scanner varene kunden forelegger. 2. Etter ferdig scanning beregner aktøren beløps/vareinformasjon og presenterer dette for kunden. 3. Aktør tar betalig og validerer betalingskort eller mynt/seddelinnkast. 4. Aktør sender melding til modulen om at transaksjonen er ferdig. 5. Modulen oppdaterer kundens profil med betalte varer. 6. Aktør ferdigstiller transaksjonen i eget system og skriver ut kvittering. 7. Modulen logger ut kunden og nullstiller terminal. ALTERNATIV HENDELSESFLYT Punkt 2. Kunden velger å avbryte transaksjonen. Punkt 3. Ugyldig betalingsmiddel, gå til punkt 3 eller avbryt. Feil: Handlevogn blir ikke registrert i betalingssone. Aktør viser en feilmelding. Side 9 av

10 4. Begrensninger 4.1 Software design begrensninger Software standarder og språk Systemet utvikles i Microsoft Visual Studio.Net. Utviklingsplattform er valgt på grunn av at det skal kjøres Windows CE på konsollen og applikasjonen som brukes til administrasjonsoppgaver skal kjøre på Windows plattformen, se I tillegg har de utviklerne vi har brukt før god kompetanse på.net. De eksisterende systemene kjører også på Windows Software grensesnitt Alle deler av systemet som har kontakt med omverden skal utvikles slik at de er tilgjengelig via COM grensesnitt. Dette er fordi COM er en standard objektmodell for Windows-plattformen, og gjør det enkelt for andre systemer å designe grensesnitt mot løsningen Software kommunikasjonsstandarder og grensesnitt Dette kommer an på hva slags løsning leverandør av posisjonssystemet har valgt. All kommunikasjon mellom de forskjellige systemene skal bruke TCP/IP, men om dette går over Ethernet, WLAN eller andre kommunikasjonsformer skal ikke ha noe innvirkning på systemet Database Systemet skal benytte Microsoft SQL-server. Dette valget er gjort på bakgrunn av valgt utviklingsløsning (se pkt ) og at eksisterende systemene også benytter dette databasesystemet. Da vil dette forenkle utviklingen av grensesnitt for import av data Operativsystem På konsollene skal det brukes Windows CE. Grunnen til detter er at på Windows CE har vi allerede IO tilgjengelig, og det kan kjøres på begrenset maskinvare Programmene som skal brukes til administrasjon skal kunne kjøres på Windows 2000 og nyere. Grunnen til dette er at eksisterende maskiner i butikkene kjører på denne plattformen. Serversystemene skal kjøre på Windows 2003 Server. Dette er en stabil utprøvd plattform og får dermed støtte for kravet om oppetid. 4.2 Hardware design begrensninger Konsollen på handlevognen må kunne kjøre Windows CE. Den må også være laget slik at den tåler eventuelle påkjenninger som slag og støt. I tillegg settes det krav til toleranse for skiftende luftfuktighet og temperatursvingninger. Enheten skal være batteridrevet og det stilles krav om batterikapasitet på minimum 1 time. Batteriene skal kunne lades opp ved hjelp av en trådløs ladestasjon i oppbevaringsseksjonen. Enheten skal være klar til bruk igjen etter ladning i 40 minutter. For å sikre best mulig opplading av batterier, vil ladestasjonen organiseres som et køsystem der siste vogn inn blir siste vogn ut. Dette sikre at vognen står lengst mulig til opplading hver gang. Sone senderne skal kunne dele inn sonene med mindre enn en meters overlapp eller hull. Sone detektorene skal kunne detektere sonebytte på under en meter. Den trådløse kommunikasjonen skal kunne ta seg av 500 brukere. Side 10 av

11 5. Aspekter omkring livssyklus 5.1 Dokumentasjon Det skal finnes en enkel dokumentasjon som brukerne av handlevogna i butikken kan lese for å få en enkel innføring i hvordan de bruker vogna i som hjelpemiddel i handlingen. En mer detaljert brukermanual skal også være tilgjengelig i hvert fall for betjeningen der det står beskrevet mer av funksjonene til handlevogna. Denne skal kunne benyttes av betjeningen for å hjelpe kundene med problemer i butikken. Det skal også finnes en mer detaljert dokumentasjon om hvordan nettverket og systemet er koblet sammen slik at det interne it-personalet i butikken kan feilsøke og løse mindre problemer. 5.2 Krav til support, service og vedlikehold Alt vedlikeholdsarbeid som skal utføres på systemet skal gjøres utenfor åpningstiden til butikken. Hvis et seriøst problem skulle oppstå skal en konsulent fra oss være på stedet innen 2 timer og begynt feilsøking og evt. kartlegging av problemet. Backup og eventuell gjenoppretting av backup skal tas hånd om av it-personalet i butikken og følge deres rutiner. 6. Aspekter omkring installasjon 6.1 Hardware installasjon Systemets hardware benytter i størst mulig grad den eksisterende infrastrukturen i filialene, men det kan i noen tilfeller være behov for tilpassninger. Dette gjør HW-leverandører i samsvar med lokale den lokale it-avdelingen. 6.2 Opplæring Det vil bli avholdt kurs for bruker og administratorer 2 uker i forkant av idriftsettelse. Opplæring av kunder sees vanskelig og systemet designes med tanke på dette. I tillegg vil dokumentasjon være tilgjengelig. Se pkt Side 11 av