Kapittel 1 Kravspesifikasjon 1.1 Forord Denne kravspesifikasjonen er ment som en hjelp til veileder, gruppemedlemmene og oppdragsgiver for å viske ut eventuell tvil om hva som skal lages. Ved å definere avgrensninger, funksjonalitet og nytteverdi av hva som skal lages øker vi forståelsesevnen til alle parter. Denne kravspesifikasjonen har vært til god hjelp i tilfeller hvor vi har vært usikre på om en funksjon er med i omfanget av prosjektet eller ikke. Innholdsfortegnelse 1 Kravspesifikasjon 1 1.1 Forord............................... 1 1.2 Presentasjon............................ 4 1.3 Om bakgrunnen.......................... 4 1.3.1 Motivasjon......................... 4 1.3.2 Funksjonalitet....................... 5 1.4 Kort systembeskrivelse...................... 5 1.5 Rammekrav i systemet...................... 6 1
1.6 Funksjonelle krav......................... 9 1.7 Ikke-funksjonelle krav....................... 16 2
1.2 Presentasjon Tittel Meso PDF (arbeidstittel) Definisjon Meso PDF er en webapplikasjon som skal håndtere PDF-dokumenter, fortrinnsvis kjøpskontrakter som skal fylles inn, og proseseres via web. Tjenesten skal laste inn eksisterende PDF-dokumenter og gjenkjenne hvilke posisjoner som kan fylles ut og generere opp en rekke input-felter i webtjenesten som skal kunne fylles ut direkte derfra. Oppdragsgiver skal så kunne koble opp disse skjemaene mot ny eller eksisterende kunde. Tjenesten skal også kunne lagre PDF-ene som et arkiv i skyen. Gruppemedlemmer Erik Maximilian Forsman Lars Henrik Nordli Simen André Hansen Gruppenummer 32 Oppdragsgiver Meso Capital Markets Kontraktperson hos oppdragsgiver Investeringsrådgiver Lasse Bøe 451 79 539 lb@mesocm.no Intern veileder Høgskolelektor Yngve Lindsjørn yngve.lindsjorn@hioa.no 1.3 Om bakgrunnen 1.3.1 Motivasjon Meso PDF er en webapplikasjon som fungerer som et CRM-system for bedriften Meso Capital Markets, som heretter vil bli referert til som oppdragsgiver. Webapplikasjonen er en reaksjon på utfordringene som oppdragsgiver har hatt tidligere, og kan bli beskrevet slik: Enklere utfylling av kjøps- og salgskontraker som før ble fylt ut med penn og papir og gjennom utallige kopierings- og utskrivningsprosesser. Disse prosessene blir forenklet i webapplikasjonen ved å lagre kundeinformasjon og digitalisere kontraktskrivingsprosessen. 3
1.3.2 Funksjonalitet Webapplikasjonen skal ha mulighet for at en bruker skal logge inn, for så å komme til en side hvor den kan velge mellom forskjellige handlinger som skal gjøres. Herunder kjøp, salg eller kjøp og salg. Brukeren skal også ha mulighet til å laste opp vedleggsskjemaer til kontraktene, hvor disse skal analyseres for utfyllbare felter og lagres i databasen. Brukeren skal så kunne velge å knytte en kontrakt, med tilhørende vedleggsskjema(er), til en ny eller eksisterende kunde. Kontrakten og tilhørende vedleggsskjema skal så fylles ut med (oppgitt) kundeinformasjon og eventuell annen gjentakende tilleggsinformasjon slik at dette ikke trengs å skrives inn flere ganger. Ansvarlig ansatt, kontrakt, vedleggsskjemaer og kundeinformasjon samt knytningen mellom disse skal så lagres i en database og gis mulighet til å skrive ut og sendes på e-post til valgte parter og eventuelt lagres på brukernes egne datamaskiner. Brukerne skal også ha roller som bestemmer tilgangsnivåer som se, opprette, endre slette og lignende. Applikasjonen skal være webbasert og skal primært fungere på bærbare og stasjonære datamaskiner, og idéelt også smarttelefoner og nettbrett med nettlesere. 1.4 Kort systembeskrivelse Systemet skal effektivisere og forenkle prosessen med å skrive kontrakter, med og uten kontraktvedlegg, og å knytte de opp mot nye eller eksisterende kunder. Dette gjøres i dag med penn og papir. Webapplikasjonen skal ha følgende overordnet funksjonalitet: Opprette, endre og vise kunde Opprette, endre, slette og vise ansatte Opprette, endre og vise kontraktvedleggsskjema Opprette, lagre og vise en kontrakt, og knytte denne opp mot ansatt, kunde og kontraktvedleggsskjema Kansellére kontrakt Skrive ut kontrakt 4
Sende kontrakt med tilhørende kontraktsvedlegg og kundeinformasjon på e-post til valgte parter Lagre alle kontrakter på egen datamaskin Se figur 1.1 for å se generell gang i systemet, og figur 1.2 for en skisse av databaseoppsett. Figur 1.1: Figur av den generelle gangen i systemet. 1.5 Rammekrav i systemet Følgende rammekrav og forutsetninger er satt for systemet: Webapplikasjonen krever en bærbar eller stasjonær datamaskin og/eller smarttelefon/nettbrett for å kunne brukes. Webapplikasjonen krever en nettleser for å kjøre. Dette følger med de aller fleste nye og eldre datamaskiner. Dette kan være nettlesere som Mozilla Firefox, Microsoft Internet Explorer, Google Chrome og lignende. 5
Figur 1.2: Skisse av databaseoppsett. Webapplikasjonen krever at enheten den kjører på har tilgang til internett. Hastighet er ikke et krav for at webapplikasjonen skal fungere. Webapplikasjonen krever at oppdragsgiver selv har server eller at leverandør av serverløsninger eksisterer. Oppdragsgiver og/eller leverandør er ansvarlig for oppetid. Verktøy som skal taes i bruk i utviklingen: Netbeans IDE som teksteditor Git og GitHub for versjonskontroll Adobe Photoshop CS5 for design og mock-ups 6
Adobe Acrobat Reader Pro til PDF-håndtering Dia for tegning av figurer og diagrammer WAMP/LAMP til lokalt testmiljø Trello til SCRUM-metodikk Programmeringsspråk som skal taes i bruk i utviklingen: HTML5 CSS3 JavaScript/jQuery PHP5 PHP-rammeverket Laravel LESS MySQL Bash Powershell 7
1.6 Funksjonelle krav 2 A En admin skal kunne legge til en ny bruker 3 A En bruker skal ha en profil som viser personalia 4 A Brukerprofilen skal vise hendelseslogg for brukeren 5 A En admin skal kunne endre på brukerpersonalia og rolle # Prioritet Krav Spesifisering 1 A En bruker skal kunne logge En bruker får tildelt innloggingsinformasjon inn for å få aksess til systemet. Når en admin har mulighet til å legge til flere brukere i systemet. En bruker har oversikt over personaliaen på en egen side samt andres så fremt de har en rolle som gir tilgang En bruker kan se sin egen logg og andres logger så fremt de har en rolle som gir tilgang En bruker med admin-rolle kan endre personalia på alle brukere i systemet med unntak av passord. 6 A En bruker skal ha en rolle Hver enkelt bruker som blir lagt til skal ha en rolle som har gitte muligheter. 7 A En bruker skal ikke kunne utføre uautoriserte handlinger/operasjoner 8 A Systemet skal forhindre uautorisert tilgang til kundeinformasjon 9 A Systemet skal forhindre uautorisert tilgang til kontrakter og vedlegg All funksjonalitet og sider sjekker innlogget brukers rolle for å se om den har tilgang. Hver enkelt kunde har en tilgangsliste med handlinger som styrer hvem som ser og får gjort hva. Når det ikke er mulig å få frem denne informasjonen uten at man er logget inn og har riktige tilgangsnivåer. 8
10 A En bruker skal kunne legge til en kunde 11 A En kunde skal kunne være privatperson eller bedriftskunde 12 A En kunde skal ha en kundestatus Brukeren har mulighet til å legge til nye kunder Bruker får opp valg om kundetype ved opprettelse. En kunde har en standard kundestatus ved opprettelse, men kan senere endres til ønsket status (Herunder avsluttet kundeforhold) 13 A En kunde skal ha en profil Bruker får (såfremt man har tilgang) tilgang på kundeprofil 14 A En kundeprofil skal inneholde detaljer om kunden 15 A En kundeprofil skal vise hendelsesloggen for kunden 16 A En kundeprofil viser alle kontrakter og maler tilhørende kunden 17 A En kundeprofil skal vise de funksjoner innlogget bruker har i henhold til tilgangsnivåer. 18 A En kontrakt skal kunne inneholde en utfylt versjon av malene. 19 A En kontrakt skal kunne inneholde vedlegg Bruker får (såfremt den har tilgang) opp detaljert kundeinformasjon Bruker har (såfremt den har tilgang) mulighet til å se på loggen til kunden om hva som er gjort/logget Bruker har (såfremt den har tilgang) mulighet til å liste opp ønsket informasjon om kunden Bruker har de valg den skal ha i henhold til de tilgangsnivåer den har til kunden (Om noen). Bruker har mulighet til å fylle ut malene og knytte de mot en kontrakt Bruker har mulighet til å laste opp vedlegg og knyte de mot en kontrakt 9
20 A En kontrakt skal ha en kontraktstatus 21 A En kontrakt som er signert skal ikke kunne endres. 22 A En signatur skal ikke kunne gjenbrukes på fler kontrakter 23 A En bruker skal kunne legge til PDF-mal tilknyttet en kunde 24 A En bruker skal kunne legge til en generell PDF-mal 25 A En bruker skal kunne oppdatere malversjon 26 A Systemet skal analysere et PDF-skjema for digital utfylling av felter. 27 A Systemet skal logge hendelser gjort på bruker og av hvem 28 A Systemet skal logge hendelser gjort på kunde og av hvem En opprettet kontrakt har en standard status som kan endres i henhold til fremdrift En kontrakt som er satt til signert er låst for endring En signatur er knyttet til en kontrakt og ikke vil være gyldig for andre kontrakter på samme kunde En bruker kan velge en kundespesifikk PDF-fil for opplasting. En bruker kan velge en generell PDF-fil for opplasting som skal være tilgjengelig for alle kunder En bruker kan erstatte mal med oppdatert versjon En opplasting av mal fører til en analyse av dokumentet som gjør det mulig å digitalt fylle ut PDF-filen En brukerspesifikk endring/handling blir logget på brukeren, også hvem som har foretatt dette En kundespesifikk endring/handling blir logget på kunden, også hvilken bruker som har foretatt dette 10
29 A Systemet skal kombinere kundeinformasjon og generere opp en eller flere PDF-dokumenter, basert på denne informasjonen 30 A Systemet skal filtrere ut hvilke PDF-maler som skal fylles ut avhengig av handlingen som velges 31 A En bruker skal kunne velge kontrakttype ved opprettelse av kontrakt 32 A En bruker skal kunne endre passord 33 A Systemet skal bruke SSLkryptering i all interaksjon med bruker 34 A Systemet skal lagre ferdige PDF i et arkiv 35 A Systemet skal tilby muligheten å laste ned alle dokumentene knyttet til en kunde 36 A Systemet skal kunne printe ut ferdige PDF 37 C En kunde skal kunne logge inn på sin profil Informasjon som er lagret på kunden i systemet blir ferdig utfylt på skjemaene Brukeren har valgt hva slags kontrakt som skal opprettes og kun de nødvendige malene kommer opp for utfylling Brukeren får mulighet til å huke av hva slags kontrakt som skal opprettes før prosessen går videre En bruker kan gå inn å endre passord på innloggingen Alle kommunisering mellom tjener og server er kryptert Alle filer i en kontrakt lagres i et eget arkiv for ferdige og signerte kontrakter En bruker skal enkelt sikkerhetskopiere alle dokumenter tilkyttet en eller flere kunder til lokal kopi Nå en kontrakt er opprettet skal det være mulig å skrive ut feridige dokumenter rett i løsningen Når en kunde kan logge inn på sin profil med oppgitt brukernavn og passord 11
38 A Systemet skal kunne sende mail til kunden nå er kontrakt er laget med kunden 39 B En bruker skal kunne redigere egen profil 40 B En bruker skal kunne legge til manuelle oppføringer i kundelogg 41 B Systemet skal tilby kategorier for manuelle oppføringer 42 C En bruker skal kunne opprette et prosjekt 43 C En bruker skal kunne knytte en kunde mot et prosjekt. 44 C En kunde skal ha oversikt over hvilke prosjekter det er i 45 C Et prosjekt skal være tilknyttet kunder og deres andel i prosjektet Systemet skal sende en bekreftelse på inngåtte avtaler gjort med en kunde. Når bruker fullfører en kontrakt, og setter status som fullført. En bruker skal kunne endre personinfo på sin egen profil. Bruker av systemet skal kunne logge ulike interaksjoner gjort med en kunde. Være seg telefonsamtaler, eposter, møter etc. Dette skal legges inn på en brukers profil, og inneholder bruker, dato, kategori og kommentar En bruker skal kunne legge til ukategoriserte oppføringer på en kunde. En bruker skal kunne laget et nytt prosjekt hvor sentral informasjon skal kunne vises i en Prosjekt profil. Et prosjekt skal kunne ha tilknyttet en eller flere kunder. Det skal vises på en kundes profil hvilke prosjekter kunden er den del av. En kunde skal ha en andel tilknytning i prosjektet. 12
46 D En bruker skal kunne opprette møte/avtale med kunde. 47 D En bruker skal ha tilgang til Min kalender som viser kommende møter/avtaler. 49 D Laste inn Excelfiler med informasjon om prosjekt og tilhørende kunder som integreres i systemet 50 D Eksportere utgående korrespondanse med dato til Excel 51 D Dokumenter skal kunne signeres med elektronisk signatur ( ved hjelp en digital skrivefalte) 52 A En bruker skal kunne opprette en kontrakt med en kunde 53 A Systemet skal kunne søke etter kunder/prosjekter etter gitte kriterier Systemet har en ønsket funksjon om en kalander hvor brukere kan legge inn fremtidige møter og avtaler med kunder. En bruker skal kunne se sine avtaler i kalenderen i en oversiktlig struktur som viser nærstående avtaler. En bruker skal kunne importere større lister med data som skal brukes til å opprette nye kunder i systemet. En bruker skal kunne eksportere aktiviteter fra hendelsesloggen til et Excelark. Basert på kunde, prosjekt og tidsintervall. Et dokument skal kunne signeres av kunden ved hjelp av en digital skrivefalte, og legges på et dokument. Prosessen skal føre til gyldige dokumenter. En bruker (såfremt den har tilgang) kan opprette en kontrakt med tilhørende dokumentasjon. En bruker har tilgang til en søkefunksjonalitet som gir de llister over data i systemet 13
54 A En bruker med tilgang skal kunne redigere tilgang til kunde 55 B En admin skal kunne redigere roller 56 A En bruker skal bli blokkert etter x antall feilinnlogginger 57 A En bruker skal kunne få et midlertidig passord på mail En bruker som allerede har rettigheter for dette på kunden kan legge til/fjerne andre brukere En bruker mer admin-rolle også har mulighet til å styrke hvilke tilganger hvilke roller har og legge til/endre på roller En bruker ikke får logget inn med sitt vanlige passord om han har nådd antall feilinnlogginger En bruker mottar midlertidig passord på mail som kan benyttes for å gjenopprette profilen Tabell 1.1: Figur over funksjonelle krav Merk! Krav med prioritet lavere enn B blir ikke prioritert som en del av fremdriftsplanen for hovedprosjektets rammer, men kan være aktuelle for videreutvikling av webapplikasjonen. 14
1.7 Ikke-funksjonelle krav # Prioritet Krav Spesifisering 58 A Systemet skal være brukervennlig og raskt Brukerne er fornøyde med hvordan systemet er laget og at de er fornøyde med 59 B En bruker skal ikke bruke mer enn 10 minutter på en hovedprosessen (i verste tilfelle) 60 A En bruker skal ikke trenge mer enn to klikk i menyen for å komme til ønsket menyvalg 61 B Nettsiden skal kunne tilpasse seg ettersom brukeren har en bærbar eller stasjonær enhet, nettbrett eller smarttelefon 62 A Systemet skal kunne utvides på en enkel måte 63 A Spørringer fra databasen skal ikke ta mer enn 2.5 sek ved normal bruk og i verste tilfelle 64 A Systemet skal ha et innbydende og funksjonelt design Tabell 1.2: Figur over ikke-funksjonelle krav farten Gangen i systemet er så raskt at det ikke tar mer enn 10 minutter å gjennomføre en hovedprosess Menyhierarkiet ikke har mer enn to forgreninger Nettsiden skaleres og er brukervennlig på alle tre enhetstyper Systemet skal utvikles etter standarder og god praksis slik at opplæring og vedlikehold av andre enn utviklerne er mulig Spørringer mot databasen skal hente så lite som mulig slik at en spørring ikke tar med enn 2.5 sekunder Brukerne av systemet synes designet er rent, pent og satt opp slik at det er lett å gjøre det man vil 15
Merk! Krav med prioritet lavere enn B blir ikke prioritert som en del av fremdriftsplanen for hovedprosjektets rammer, men kan være aktuelle for videreutvikling av webapplikasjonen. 16