2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie
Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt som skal gjennomføres ved Høgskolen i Oslo og Akershus for Informasjonsteknologiavdeling i samarbeid med Gilje AS. Prosjektet går ut på å utvikle en nettløsning for Gilje Selskapslokaler. Nettløsningen skal inneholde en presentasjon av selskapet, deres lokaler, Mathilde og et reservasjonssystem. Nettløsningen skal inneholde en admin-portal der ledere og ansatte kan administrere nyheter og forespørsel. Det skal også være en portal for andre medlemmer/brukere som får tilgang til dokumenter, sanger, nyheter etc fra databasen. Vi vil utvikle systemet ved hjelp av.net og JavaScript. 1.2 Om Gilje Gilje har en lang historie som selskapslokale i Askim. Det benyttes til bryllup, jubileer, begravelser, møter etc. Selskapet er et AS og heleid av Klubben som er en medlemsklubb hvor det blant annet spilles bridge. Catering-selskapet, Mathilde, har etablert seg i lokalene og skal samarbeide med Gilje om arrangementer. 1.3 Bakgrunn for prosjektet Gilje har per dags dato ingen nettløsning for informasjon eller reservasjon. De leier ut i dag lokalet etter avtale over telefon eller i person, men dette er et tungvint system som krever mye tid siden kundene ikke kan finne informasjon på nettet. Mathilde har egen nettside, men både Gilje og Mathilde vil tjene på at selskapene promoteres på hverandre nettsider. Ønsket er at Gilje skal få en nettløsning som promoterer Gilje Selskapslokaler, gir god informasjon til potensielle kunder og blir en felles database for medlemmer av Gilje. 1
2 Forord 2.1 Forord Denne kravspesifikasjonen beskriver betingelse for prosjektet "Gilje Selskapslokaler". Kravene til funksjonalitet og rammebetingelser er beskrevet i dette dokumentet. Hovedkravene om funksjonalitet og design er gitt av Gilje AS, men hvordan prosjektet spesifikt og best mulig skal løses har prosjektgruppa styrt selv. 2
3 Innhold 1 Presentasjon... 1 1.1 Innledning... 1 1.2 Om Gilje... 1 1.3 Bakgrunn for prosjektet... 1 2 Forord... 2 2.1 Forord... 2 3 Innhold... 3 4 Systemkrav... 4 4.1 Funksjonskrav... 4 4.1.1 Krav til hjemmeside... 4 4.1.2 Krav til medlemsportal... 5 4.1.3 Krav til administrasjonsportal... 5 4.1.4 Krav til administrasjon av reservasjoner... 5 4.1.5 Teknisk krav... 6 4.2 Datalagring... 6 4.2.1 Krav til datalagring... 6 5 Krav til design... 6 5.1 Design mål... 6 5.1.1 Generelle designmål... 6 5.1.2 Designmål reservasjon... 7 5.1.3 Designmål brukerportal... 7 5.1.4 Designmål administrasjonsportal... 7 5.1.5 Designmål administrasjon av reservasjoner... 8 6 Kode... 8 6.1 Krav til kode... 8 7 Dokumentasjon... 9 7.1 Krav til dokumentasjon... 9 7.2 Eventuelle krav til sikring mot tap av data... 9 8 Utvidelser... 9 8.1 Eventuelle utvidelser... 9 3
4 Systemkrav 4.1 Funksjonskrav 4.1.1 Krav til hjemmeside 1. Siden skal være strukturert og ryddig slik at det er lett for kunder å finne og navigere seg frem. 2. Den statiske delen av siden skal bestå av en logo i toppen av siden og en menylinje under som gjør det enkelt for brukeren å finne fram på siden. 3. På forsiden skal det være en seksjon for levende bildeshow av lokalet. 4. Reservasjonssystem skal bestå av kalender oversikt over ledige dato. Her kan kunde velge den dato som passer og sende en forespørsel om utleie. Ved forespørsel vil det være en vanlig opplysningsregistrering av vedkommende og ikke minst formål med utleie. Forespørsel vil bli sendt pr e-post og vil bli behandlet manuelt av ansatte. 5. Administrasjon av reservasjoner trenger ikke være en del av nettsiden. Dette kan gjøres på annen måte så lenge det jobber mot samme database som nettsiden benytter til å vise status på datoer/reservasjoner 6. Det vil være en link til Mathilde.no på siden hvor kundene kan få oversikt over matmenyer og andre delikatesser. Det er ønskelig å få hente meny fra Mathilde.no til en side på Gilje's nettside også. 7. Gilje ønsker at brukere som besøker nettsiden skal få svar på: Tilgjengelighet Hvordan få besiktiget Hvordan ser fasilitetene ut (Godt bildegalleri ute/inne ) Parkering Offentlig transportmidler (kart) HC tilgjengelighet Meny Serveringsopplegg Drikke / alkohol Målgruppe Kapasitet Standard leieavtaler Kontakt info Giljes historie 4
4.1.2 Krav til medlemsportal 1. Medlemsportalen skal ligge på eget domene. Det skal ikke linkes fra hjemmesiden til Gilje til medlemsportalen. 2. Portalen skal ha pålogging med brukernavn og passord. 3. Det skal også være mulig for administrator å logge på siden for vedlikehold og administrasjon av siden, brukere og dokumenter. 4. Administrator skal også kunne legge til nyheter for hjemmesiden til Gilje. 5. Dokumenter skal kunne lagres og søkes opp gjennom database. 6. Dokumenter skal kunne arkiveres predefinerte grupper (f.eks.: Sanger, møtereferat..) 7. Referater fra møter skal kunne sorteres på dato. 8. Det skal være en link til alle selskapssanger. 9. Sanger skal kunne lagres i grupper som hører sammen (f.eks.: selskapssanger, sanger til maten, etc..) 10. Det skal være mulig å hente ut en medlemslist. 11. Ved innlogging skal medlemmet få en oversikt/presentasjon av nyheter/meldinger som angår medlemmer av Gilje Selskapslokaler. 12. Brukere skal ha et tilgangsnivå som gir de tilgang til det de trenger. For eksempel trenger ikke alle ha tilgang til møtereferater. 4.1.3 Krav til administrasjonsportal 1. Administratorsiden skal det være for administrasjon av dokumenter, medlemslister, møtereferater, og sanger. Administrator skal kunne legge til, gjøre endring og sletting her. 2. Administrator skal kunne legge til nyheter, møteinnkallelser etc som medlemmer får presentert ved påloging. 3. Administrator skal kunne legge til og fjerne predefinerte dokumentgrupper. 4. Predefinerte grupper som inneholder dokumenter skal ikke kunne fjernes. 4.1.4 Krav til administrasjon av reservasjoner 1. Administrasjon av reservasjoner trenger ikke gjøres på nettsiden, men må jobbe mot samme database som nettsiden benytter til å vise status på datoer/reservasjoner. 2. Administrasjon av reservasjoner kan gjøres på en egen nettside, men må ha sikkerhet i form av brukernavn og passord 3. Brukeren/Administratoren av reservasjonssiden skal ha mulighet til å endre passord. 5
4.1.5 Teknisk krav 4.2 Datalagring 1. Programmet som skal brukes er Microsoft Visual Studio 2012. 2. Utvikles med C# i MVC 4. 3. Det skal brukes JavaScript for å gjøre brukeropplevelse bedre. 4. Lagring av data vil skje i MySQL 5.6. 5. Nettsiden skal driftes på en Linux-server. 4.2.1 Krav til datalagring 1. All data som skal lagres eller hentes foregår i en MySQL-database på serveren. 2. Validering av data skjer før innsetting, både i inputfeltene og i databasespørringene. Dette er et krav om god sikkerhet med tanke på sql-injections. 3. Alle data skal passordbeskyttes og det er kun brukere som har rettigheter og tilgang til forskjellige data. 4. MySQL-databasen skal være bygd opp med krav om normalisering. 5 Krav til design 5.1 Design mål 5.1.1 Generelle designmål 1. Brukere skal kunne behandle og forstå hver eneste del av siden personen har tilgang til, uten å trenge datakunnskaper. 2. Det meste av design skal kodes i CSS og ikke direkte inn i cshtml-filene. Dette blir mer oversiktlig for eventuelle andre som overtar koden. 3. Designet skal være svært ryddig, pent og oversiktlig. Det skal være behagelig å se på bilder samt at det ikke skal være forstyrrende å lese tekst. 4. Øverste del av siden skal være statisk, med logo og menylinje. Dette sikrer enkel navigering på siden. 5. Ved å klikke på et menyvalg i toppen av siden kan brukeren få ytterlige valg tilgjengelig på venstre side av hovedsiden om det trengs for å katalogisere informasjon som hører til under menyvalget. 6. Linker skal navngis på norsk for enkel navigering. 7. Målgruppen forventes å være norsk så det er ikke planlagt oversettelse av siden. 6
5.1.2 Designmål reservasjon 1. Reservasjonen skal se ut som stor kalender som man kan se hvilke datoer og tider som er tilgjengelige. 2. Det skal være farger for de datoene som er ledige, opptatte eller delvis opptatt. Det skal være lett for bruker å fort oppfatte hva de forskjellige fargene betyr ved hjelp av en beskrivelse ved kalenderen. 3. Kalenderen skal være godt forståelig og skal sende bruker til et kontaktskjema hvis personen klikker på en dato. 4. Kalenderen skal ikke være en automatisk reservasjon, men det skal være en oversikt for administrator og brukere for å vite hvilke datoer som er opptatt og hvilke datoer man kan sende en forespørsel om. 5. Bruker skal få bekreftelse på e-post om hvilke valg og forespørsel kunden har gjort til administrator. 5.1.3 Designmål brukerportal 1. Det skal være en egen innloggingsside før bruker kommer til selve portalen. 2. Når brukeren er innlogget skal han/hun se en side der nyheter/beskjeder blir presentert. 3. Sidene skal overskrift og menylinjen i toppen tilsvarende designet til Gilje's hjememside. Detter for å bevare et kjent miljø for brukeren. 4. Brukeren hører til et tilgangsnivå som bestemmer hva han/hun skal ha tilgang til, men dette skal ikke være noe brukeren skal se. Brukeren skal ikke se begrensningene ved sin klarering. 5.1.4 Designmål administrasjonsportal 1. Administrasjonssiden skal kun være en utvidelse av brukerportalen. 2. Designet skal holdes likt, men muligheter for administrering skal komme opp som en del av valgene. 3. Sidene skal fortsatt ha logoen og menylinjen i toppen for å bevare et kjent miljø for brukeren. Ytterlige muligheter blir tilgjengelig på hovedsiden i form av en meny på venstre side. 4. Brukeren hører til et tilgangsnivå som bestemmer hva han/hun skal ha tilgang til, men dette skal ikke være noe brukeren skal se. Brukeren skal ikke se begrensningene ved sin klarering. 7
5.1.5 Designmål administrasjon av reservasjoner 1. Siden skal være så enkel som mulig. Brukeren/administratoren skal møtes av en enkel innlogging med brukernavn/passord forespørsel. 2. Når brukeren/administratoren er logget inn skal han/hun se kalenderen med mulighet for å legge inn reservert, delvis reservert eller opphev reservasjon pr dato. 3. Det skal kunne legges inn tidsrom på datoer som er delvis reservert. 6 Kode 6.1 Krav til kode 1. ASP-kontrollere (Label, TextBox etc.), metoder og variabler skal ha naturlige navn i forhold til den konteksten de er i. F.eks. en tekstboks med input navn må kalles "navntextbox". 2. Kodefilene skal kommenteres i henhold til C# XML standard som det er støtte for i C# kompilatoren. F.eks.: /// <summary> /// Metode for når bruker trykker på "nullstill"-knapp /// </summary> /// <remarks> /// Navn og telefonnummer felter blir satt til blanke /// </remarks> /// <param name="sender">objekted clicked/selected</param> /// <param name="e">eventargs</param> private void Clear_Click(object sender, EventArgs e) { navntextbox.text=""; tlftextbox.text=""; } 8
7 Dokumentasjon 7.1 Krav til dokumentasjon 1. Det skal innføres daglig logging av hva som er blitt gjort. Her skal det forklares utfordringene som vi møter og hvordan vi løste de. 2. Referater fra møter skal dokumenteres. Gjelder både møter med Gilje og gruppe. Møter med Gilje føres i egne møtereferat mens gruppemøter føres i arbeidslogg. 3. Det ferdige prosjektet skal dokumenteres gjennom: Kravspesifikasjon Prosessrapport Produktdokumentasjon Brukerdokumentasjon Testrapport 7.2 Eventuelle krav til sikring mot tap av data 3. All dokumentasjon og data skal lagres på Dropbox delt mellom prosjektmedlemmene og Gilje. 4. Det skal tas en modulær backup som f.eks. med en minnebrikke eller ekstern harddisk. 8 Utvidelser 8.1 Eventuelle utvidelser 9