Kravspesifikasjon Prosjekt nr SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 8 Intern veileder: Kjetil Grønning

Transkript

1 Prosjekt nr Kravspesifikasjon Tittel: Informasjonssystem SSPI Prosjektdeltakere: Hans Petter Kristiansen Espen Skaarer Dato: 25.mai 2007 Antall sider: 8 Intern veileder: Kjetil Grønning Oppdragsgiver: SSP Installasjon AS ( Kontaktperson: Kai Evjen Side 1

2 1. Forord Denne kravspesifikasjonen beskriver betingelser for vårt hovedprosjekt for SSP Installasjon AS. Krav til system, funksjonalitet, design, datalagring, kode, dokumentasjon og eventuelle utvidelser er beskrevet i dette dokumentet. Hovedkrav og retningslinjer for systemet som skal utvikles er gitt av SSP Installasjon AS, mens det er opp til gruppas medlemmer å komme opp med løsninger på de spesifikke krav. Side 2

3 2. Innholdsfortegnelse 1 Forord...Side 2 2 Innholdsfortegnelse...Side 3 3 Innledning...Side Innledning...Side Om bedriften...side Bakgrunn for prosjektet...side 4 4 Systemkrav...Side Systemkrav...Side Krav til ordresystem...side Krav til administrasjonsdel...side Krav til statistikk og rapportdel...side Krav til hjemmeside...side Tekniske krav...side Datalagring...Side Krav til datalagring...side 6 5 Design...Side Krav til design...side 7 6 Kode...Side Krav til kode...side 7 7 Dokumentasjon...Side Krav til dokumentasjon...side Prosjektdokumentasjon...Side Systemdokumentasjon...Side 7 8 Utvidelser...Side 8 Side 3

4 3. Innledning 3.1 Innledning Vi utfører dette prosjektet som et hovedprosjekt ved HiO avd. for ingeniørutdanning. Oppgaven består av å lage en webløsning for SSP Installasjon AS med både internløsninger og løsninger for fremtidige kunder. Ved utviklingen av dette systemet vil vi bruke jsp, java. 3.2 Om bedriften SSP installasjon AS er en nyetablert bedrift som hovedsakelig har sin virksomhet innen salg og utførelse av installasjonstjenester innen svakstrømsområdet. Blant annet er SSP subleverandør av installasjonstjenester for Norges største sikkerhetsbedrift. SSP består av 7 ansatte og er lokalisert på Tåsen i Oslo. Bedriften er i vekst og estimerer selv at de vil være ca ansatte i løpet av 2007, samt en omsetning lik kr ,- i De har et langsiktig mål om å oppnå en årlig omsetning lik kr mill i løpet av de neste 4 år. 3.3 Bakgrunn for prosjektet SSP har en noe manglende infrastruktur når det gjelder IT baserte støttesystemer, blant annet er en av deres største suksesskriterier å etablere et smidig ressursstyringssystem. Av andre vesentlige behov nevnes etablering av hjemmeside og rapportering. Disse behovene er fremkommet via et møte med bedriften hvor SSP skisserte hvilke utfordringer de står ovenfor rent IT messig. Side 4

5 4. Systemkrav 4.1 Funksjonskrav Krav til ordresystem Når en ordre blir lagt inn i systemet, vil den ikke umiddelbart bli tildelt en dato for utførelse. Dette er opp til montøren å booke selv. HK legger inn ordrer, og så vil montøren få mail om at nye ordrer venter, for så å logge seg inn på nettsidene og booke dato og klokkeslett. Montørdel: Alle montører skal kunne logge seg inn og sjekke sine servicer. Hver enkelt montør har oversikt over de servicer som er booket, de som han/hun skal booke, samt utførte servicer. I oversikten over servicer som ikke er booket skal den som standard sorteres etter dato den ble lagt inn i systemet. Montør kan likevel sortere etter egne kriterier ved å trykke på overskriftene, hvis det er mer ønskelig for eksempel å booke servicer som ligger nære hverandre geografisk. Hvis en ordre har ligget i systemet i mer enn en uke skal bakgrunnsfargen på denne endres til gult, slik at montøren ikke vil glemme en ordre. Hvis servicen har ligget i systemet mer enn to uker skal den blir rød. Hver ordre vil i denne oversikten ha en status. De forskjellige statusene en service har, skal være: ikke ringt, ringt en gang, ringt to ganger, ikke fått kontakt med kunde og booket. Når montøren får tak i kunden og skal booke inn service, trykker han/hun bare på en knapp med teksten book service. Montøren vil da sendes videre til en side med kalender og dagsoversikt. Her vil ledige servicetider ligge under hver enkelt dag, og montøren skal trykke på valgt klokkeslett for å reservere. Dette skal bekreftes med en ok/avbryt-boks. I oversikten kan også montøren velge å avvise en ordre. Denne vil da bli sendt tilbake til bookingavdelingen. På hver dagsoversikt skal montøren ha mulighet til å printe ut en oversikt over dagen med alle servicer. Bookingdel: Når ansatte på hovedkontoret får inn servicer som må utføres fra deres kunder har han/hun to valg. Enten kan tidspunkt for service bookes direkte inn i kalender til en valgt montør, eller så kan de bare tildele denne servicen til en montør, hvor montøren selv må ringe kunde og avtale tidspunkt. Hvis montører får slike åpne arbeidsordrer skal de informeres på mail om at de har ventende servicer. Det skal maks komme en slik mail om dagen. De kan også laste opp hele.xls-dokumenter, og direkte tilegne disse til en enkelt montør, eller legge disse i et åpent register for senere montørtideling. Administrasjonsdel: Administratorer av systemet skal ha alle rettigheter. De skal kunne se oversikt over alle montører, alle servicer, og også sortering av disse. De skal også ha mulighet til å endre og flytte på servicer, samt trekke disse tilbake fra montører. Administratorer skal også kunne laste opp.xls-dokumenter med ordrer. Disse skal enten tilegnes en montør direkte, eller legges i et åpent register for senere montørtildeling. Kundedel: Kunden skal ha mulighet til å se når deres service er booket. For enkelte store bedriftskunder skal det også være mulighet til å se oversikt over alt som er utført for dem. Dette skal ikke være mulig for privatkunder. Side 5

6 4.1.2 Krav til administreringsdel Administratorer skal ha alle muligheter i systemet. De skal ha alle rettigheter i ordresystemet. De skal også ha en del administrative muligheter, slik som oppdatering av postnummerliste fra postens egen postnummeroversikt, legge til og endre ansatt/kunde-informasjon, administrere nyheter for hjemmesiden inkl. ledige stillinger, samt se rapporter over utførte oppdrag og annen relevant informasjon Krav til statistikk og rapportdel All statistikk og de fleste rapporter skal kun være tilgjengelig for administratorer av systemet. Det vil likevel være behov for at enkelte utenforstående skal ha tilgang til noen av SSPI s rapporter. Dette skal være begrenset i systemet av administratorene. Statistikken og rapportene skal så fremt det er mulig presenteres på en best mulig måte og med grafiske diagrammer hvor dette er nødvendig. Det skal være mulig å hente ut rapporter og statistikk for: Alle bestillinger Alle bestillinger som ikke er utført Alle bestillinger som er utført Alle ordrer på hver enkelt montør Krav til hjemmeside Hjemmesiden skal i tillegg til fuksjoner nevnt tidligere i dette dokumentet også inneholde elementer som stillinger, nyheter, om sspi og produkter. Under stillingsdelen skal det også være oversikt over de til enhver tid ledige stillingene i bedriften. Disse skal listes opp med stillingstittel, sted, dato og søknadsfrist. Ved å trykke på en stilling skal det vises detaljer for den aktuelle stillingen. Det skal under venstresidemenyen listes opp de siste tre nyheter. Disse skal kortes ned til en fornuftig lengde, slik at de ikke opptar for mye plass. Ved å trykke på les mer vil hjemmesidebrukeren kunne se hele nyheten. Alle nyheter skal listes opp under nyheter -siden. På produktsiden skal det vises alle hovedkategorier med et lite bilde. Ved å trykke på bildene, les mer, eller ved å trykke på underkategorien i menyen til venstre skal detaljer om hver enkelt produktkategori vises Tekniske krav Systemet skal utvikles i JSP og Java. For datalagring skal en MySQL-database brukes. Systemet skal være webbasert og operatørsystemuavhengig. Programmene som skal brukes under utviklingen er: Eclipse, TextPad, putty, Adobe Photoshop og FlashFxp. 4.2 Datalagring Krav til datalagring All data i systemet skal lagres i en MySQL-database på et webhotell, slik at dataene er tilgjengelig for alle deler av SSPI. Alle data skal valideres både før innlegging for å forhindre eventuelle feil, både med tanke på feil innlegging, men også med tanke på SQL-injections. Alle data skal krypteres og passordbeskyttes, siden dette kan være sensitive data for bedriften og deres kunder. Databasen skal bygges opp etter gjeldende standarder for denne type databaser. Ansatte skal likevel hentes fra bedriftens eget mamut-system. Side 6

7 5. Design 5.1 Krav til design Siden løsningen skal være webbasert vil hjemmesiden til SSPI være utgangspunkt for både potensielle kunder, eksisterende kunder, montører og ledelsen i SSPI. Denne hjemmesiden skal være representativ og inneholde informasjon om bedriften og deres tjenester og produkter. Venstredelen av hjemmesiden skal være en dynamisk meny, mens menyen i logoen skal være statisk med de forskjellige hovedfeltene til SSPI. Tilgjengelig på alle sider vil det være mulighet for å logge inn øverst til høyre. Når man er logget inn skal menyen på venstre tilpasses den gjeldende brukerens behov. For eksempel skal montører ha menyelementer som oversikt servicer, rapportere servicer og lignende. 6. Kode 6.1 Krav til kode All kode skal være oversiktlig og være kommentert på en slik måte at utenforstående i ettertid har mulighet til å endre og utvide systemet. Metoder, klasser og variabler skal være forklarende for sin funksjon, og også skrives på norsk. 7. Dokumentasjon 7.1 Krav til dokumentasjon Prosjektdokumentasjon Det skal under hele prosjektet føres prosjektdagbok. Dette skal gjøres fortløpende og skal publiseres på prosjektets hjemmeside. Denne skal inneholde den jobb som er gjort, hvor mye tid som er brukt og eventuelle problemer som har oppstått og hvordan disse er løst. Hele prosjektet skal dokumenteres i en sluttrapport Systemdokumentasjon Hele systemet skal grundig dokumenteres og alle funksjoner og deler av systemet skal inngå i en brukermanual. Side 7

8 8. Utvidelser 8.1 Eventuelle utvidelser Side 8