Mobil billettløsning Troms. Kundens kravspesifikasjon. Dato: Versjon 0.8

Transkript

1 Mobil billettløsning Troms Kundens kravspesifikasjon Versjon 0.8 Dato:

2 Innholdsfortegnelse: 1 INNLEDNING KGRUNN UTFORMING V KRV OG SVR PÅ DISSE EVENTUELT SPESIELT KOSTNDSDRIVENDE KRV DEFINISJONER OG FORKORTELSER GENERELLE KRV KRV OM HELHET I LØSNING PROSESSTØTTE NEDLSTNING, INSTLLSJON OG KONFIGURSJON V PPLIKSJON SLGSPROSESS DMINISTRSJON V EGEN RUKER RPPORTERING OG KONTROLL ILLETTKONTROLL FUNKSJONELLE KRV RUKEROPPLEVELSE GRFISK UTFORMING UNIVERSELL UTFORMING PERSONVERN SIKKERHET KRV TIL ILLETTEN RPPORTERING OG KONTROLL TEKNOLOGISKE KRV MOIL PPLIKSJON ETLINGSLØSNING OPSJONER FR OG TIL, SMT SONETILHØRIGHET VIDEREUTVIKLING OG ENDRING KRV TIL DRIFT OG FORVLTNING GENERELLE KRV TIL DRIFT KRV TIL DRIFTSPROSESSER OG SMHNDLING ETLERINGSPROSJEKT PRODUKTER MOIL ILLETTERING...16 Side 2 av 17

3 1 Innledning Dette dokumentet inneholder Troms Fylkestrafikk FKF (heretter TFT) sine krav til en tjeneste for salg av kollektivbilletter via mobil applikasjon, såkalt app. Tjenesten skal tilby en helhetlig systemløsning inkludert en mobil applikasjon for brukerne og leveres som en tjeneste som også inneholder drift, forvaltning og betalingsløsning. Hvert område er beskrevet med en innledende tekst med påfølgende krav i en kravtabell som Leverandøren skal svare på. Den innledende teksten er like forpliktene som teksten i kravtabellen. 1.1 akgrunn Det ble i 2011 besluttet et nasjonalt mål om å redusere kontanthåndteringen om bord på busser i Norge. Med bakgrunn i det har Fylkesrådet i Troms vedtatt at det skal etableres billettering fra mobiltelefon. På sikt er det et mål at passasjerene skal kunne bruke NFC-teknologi, men i påvente av at løsninger blir tilgjengelig, legges det opp til kjøp av billetter via applikasjon på smarttelefon. Dette kravdokumentet omhandler salg via mobile applikasjoner der TFT ønsker å få dette levert som en helhetlig tjeneste. 1.2 Utforming av krav og svar på disse Kravene er beskrevet tematisk og gitt en innledning i form av generell tekst etterfulgt av kravtabell. Teksten i innledningen er like forpliktene som teksten i kravtabellen. Kravtabellen inneholder 6 kolonner og vil være utformet som følger: Svar Kommentar Forklaring til de enkelte kolonnenes innhold: 1. Nummer. Oppdragsgivers nummerering. 2. Område: Kortnavn som grupperer kravene slik at de lettere kan behandles i ulike grupper. 3. Krav: Den tekstlige beskrivelsen av det enkelte kravene 4. Kat: (Kategori) En inndeling av kravene med hensyn på viktighet og behandling av disse (se under). 5. Svar*: Leverandørens svar på kravene i form av et av de angitte svaralternativer (se under). 6. Kommentar*: Eventuelle kommentarer, utfyllende informasjon, eller henvisning som hvor i løsningsbeskrivelsen eller i noen av de andre delene av kontraktsbilagene hvor svaret er beskrevet. Kolonner merket med * over skal fylles ut av leverandøren og inngår i ilag 2. Utlysningen har følgende kategorier av krav (Kat):. Dette er krav som løsningen eller tjenesten må dekke. esvarelser som ikke dekker disse vil normalt ikke bli vurdert.. Dette er krav som løsning og tjenesten bør dekke. Dette er krav som vil bli brukt til å rangere løsninger og besvarelser i forhold til hverandre C. Dette er andre krav TFT ønsker og som vil inngå i kontrakt dersom leverandør har bekreftet at de dekker dette. Oppfyllelse vil være med i vurdering av helhet, men ha lavere viktighet enn krav i kategori. D. Opsjoner, dvs. funksjoner som Oppdragsgiver ønsker tilbud på, men som kun vil bli tatt inn i kontrakt dersom TFT ønsker det. Side 3 av 17

4 Følgende svaralternativer (Svar) skal benyttes: J: J-6m: NEI: Løsningen/tjenesten vil dekke dette kravet fra start av tjenesten. Løsningen/tjenesten vil dekke dette kravet innen 6 måneder etter installasjon, senest 31.juli 2013, uten tillegg i pris. Løsningen/tjenesten vil ikke dekke dette kravet. T: Løsningen/tjenesten vil dekke dette kravet, men det kan kreve tillegg i prisen. Eventuell tillegg i pris skal være bemerket i kommentarfeltet og pris skal i så fall være tydelig spesifisert i pristabell med referanse til krav. Dersom pris ikke er tydelig angitt i pristabell antas det å inngå i standard leveranser uten tillegg i pris. Dersom dette ikke kan leveres ved start av tjenesten skal dette angis i kommentarfeltet når det kan bli levert, dog innen 6 måneder etter første installasjon, senest 30.juni Eventuelle leveranser etter denne dato vil bli betraktet som NEI. 1.3 Eventuelt spesielt kostnadsdrivende krav Dersom det er krav som ut fra Leverandørens vurdering, framstår som unødvendige sett i lys av formål og/eller helhet i tjenesten, eller som er vesentlig kostnadsdrivende skal leverandøren påpeke dette samt beskrive hvordan dette dekkes på annen måte i forhold til formål og helhet. Dette skal påpekes i kommentarfeltet på det enkelte krav med referanse til løsningsbeskrivelse. 1.4 Definisjoner og forkortelser ITIL Information Technology Infrastructure Library (ITIL) er et strukturert rammeverk og ontologi for kvalitetssikring av leveranse, drift og support innen IT-sektoren. Versjon 3.0 legges til grunn i dette dokumentet. 2 Generelle krav 2.1 Krav om helhet i løsning Leverandøren skal levere en helhetlig og komplett løsning med de elementer som er nødvendig for å levere tjenesten. lle beskrevne elementer i tabeller pkt. 2-9 skal besvares og kommenteres. Dersom det er elementer som er nødvendige eller formålstjenlige for å etablere en tjeneste med god kvalitet for TFT, skal disse tas med i tilbudt tjenesteløsning. Dersom Leverandør ser det er mangler i krav som kan medføre mangelfull løsning eller tjeneste sett i lys av formål, helhet eller lov og forskrifter, normer og standarder skal leverandør påpeke dette og tilby disse GEN Leverandøren skal tilby en helhetlig og komplett systemløsning for salg av billetter via mobile applikasjoner på Smarttelefoner. lle avhengigheter til andre systemer og tjenester samt forutsetninger skal beskrives GEN Leverandøren skal levere en helhetlig tjeneste med tilpasninger, etablering, utrulling, drift og forvaltning av salg av billetter via mobile applikasjoner inkludert betalingsløsning, avregninger og rapportering. Tjenestens komplette livssyklus skal dokumenteres og beskrives, i tillegg til at alle avhengigheter til andre systemer og tjenester samt forutsetninger skal beskrives GEN Tjenesten og systemløsningen skal leveres og driftes i henhold til gjeldende lover og forskrifter samt normer og standarder GEN Tjenesten og løsningen skal støtte og bidra til enklest og sikrest mulig kjøp av billetter via mobile applikasjoner. Side 4 av 17

5 3 Prosess-støtte Tjenesten skal dekke følgende forretningsprosesser (se figur): Mobilbillett TFT Mobil billett Nedlasting, installasjon, konfigurasjon Start Valg billettprodukt etaling og ordre Distribusjon billett Leverandørens nettløsning dministrasjon egen bruker ackoffice Rapportering og kontroll illettkontroll Kundeservice Hjelpfunksjon I tillegg til disse prosessene skal Leverandøren sikre driftsprosesser som understøtter tjenesten og som sikrer god kvalitet i denne. Disse siste er beskrevet i eget kapittel senere. Hver prosess er kortfattet beskrevet gjennom et prosessmandat med overordnede krav til prosessen i form av input output og aktiviteter og deltagere, samt med en eller flere rukstilfeller knyttet til prosessen. rukstilfellene brukes for å utvide prosessbeskrivelsen. Leverandøren skal selv beskrive hvordan deres løsning støtter de overordnede mål, hvordan de kan realisere de nevnte prosesser, og gi en utfyllende beskrivelse. 3.1 Nedlastning, installasjon og konfigurasjon av applikasjon rukstilfelle a): Finner TFT mobilbillettapplikasjon TFT Mobilbillett i pp Store eller Google Play. Laster ned app en. ksepterer betingelsene. rukstilfelle b): Trykker på applikasjonsikonet for første gang, og applikasjonen åpner seg. Kommer til en klart definert forside med fokus på konfigurering. ruker ledes gjennom en enkel oppsettsprosess. Her bestemmes betalingsmåte og ev. brukerinformasjon som vil forenkle kjøpsdialogen senere (kan for eksempel være fast startsone). Dersom prosessen avbrytes skal man komme tilbake til stedet der den ble avbrutt og det må være enkelt å gå bakover og endre oppsett. Prosessmandat: Nedlastning, installasjon og konfigurasjon av applikasjon Input rukers behov og eller ønske om å kjøpe billett via mobil applikasjoner Output: Mobil applikasjon klar til bruk på brukers smarttelefon ktiviteter Søke, finne, laste ned og installere applikasjon Deltagere: ruker, markedsplasser som pp Store og tilsvarende, baksystem. Mobil applikasjon. Side 5 av 17

6 3.1.1 PROSESS Løsningen skal støtte prosessen for nedlastning, installasjon og konfigurasjon samt de angitte rukstilfellene PROSESS pplikasjonen skal gjøres tilgjengelig i de vanligste distribusjonskanalene for sin plattform, inkludert pples pp Store, og Google Play PROSESS pplikasjonen skal være effektiv å laste ned, og installere seg automatisk PROSESS pplikasjonen skal være synlig som TFT sin applikasjon på markedsplassen. 3.2 Salgsprosess rukstilfelle c): Start av applikasjon. Trykker på applikasjonsikonet, og applikasjonen åpner seg. Kommer til en klart definert forside med fokus på salg av ny mobilbillett ( billettautomaten ). Når også annen viktig funksjonalitet enkelt fra forsiden. Om inne på undersider, enkelt å navigere tilbake til forsiden rukstilfelle d): Start av applikasjon for kjøp av min favorittbillett. Tar opp telefonen. Åpner applikasjonen. Min enkeltbillett kommer opp. Ser billettens gyldighet, gyldighetsområde og pris. ksepterer kjøp. illetten leveres. To tastetrykk for meg som kunde. Utfyllende kommentar: pplikasjonen ev. baksystemer må vite noe om kommende reise. Dette kan for eksempel defineres i brukerprofil som kan ligge lokalt i applikasjonen. Samtidig bør det være en mulighet for å lagre min billett som favoritt for senere bruk når en bestilling er gjennomført. Løsningen kan for øvrig automatisk ha sist brukte som favoritt om ikke annet er valgt. Det er opp til leverandør å foreslå den beste løsningen. rukstilfelle e): Start av applikasjon for kjøp av min favorittbillett. Startsiden er billettautomaten. illettkjøpsalternativene (voksen, barn/honnør) vises på en oversiktlig måte med tilhørende pris. Utgangspunktet er en (1) Sone Troms billett fra den sonen jeg er i. Velger antall billetter som ønskes kjøpt i hver kategori. Dermed mulighet for å bestille for flere som reiser sammen. illettkjøp her og nå med umiddelbar levering er standard og gjelder i 90 minutter etter kjøp. TFT skal kunne definere lenger gyldighetstid (inkl. overgang) dersom reisen er mer enn 1 sone, også når reisen er en kombinasjon av buss/båt/ferge. Prosessmandat: Kjøp av billett Input ruker med smarttelefon og app konfigurert og satt opp. rukers kunnskap om hvilken billett vedkommende skal ha. Output: illett vises i appen, transaksjon generelt i transaksjonslogg, betaling mottatt og kunden belastet for kost på billett... ktiviteter Valg av billett, betaling og nedlasting av billett med QR kode. Deltagere: ruker, mobil, pp installert, etalingssystem og bakenforliggende system. QR kode utsteder PROSESS Løsningen skal støtte prosessen Kjøp av billett fullt ut. eskriv grundig inkludert transaksjon PROSESS Løsningen skal støtte valg av billettprodukt, betaling og distribusjon av billett i mobil applikasjon med integrasjon mot bakenforliggende systemer. eskriv løsning PROSESS Løsningen skal støtte betaling via kredittkort PROSESS Løsningen skal støtte betaling via Mobilkonto PROSESS Løsningen skal støtte betaling via kundens mobiltelefonregning PROSESS Løsningen skal gi kunden mulighet til å velge betalingsmåte PROSESS Løsningen skal støtte kjøp av billetter med forhåndslagret betalingsinformasjon slik at kjøp kan gjennomføres på færrest mulig tastetrykk PROSESS Løsningen skal gi mulighet for utskrift av kvittering/billett som dekker kravene i forhold til bokføring og reiseregninger. eskriv løsning. Side 6 av 17

7 3.3 dministrasjon av egen bruker rukstilfelle f): Oversikt: ruker går inn på tromskortet.no, velger administrasjon av mobil billett, får tilgang til leverandørs nettsider, taster inn mobiltelefonnummer sammen med en sikkerhetskode eller tilsvarende, og får tilgang til oversikt over reiser, med muligheter for utskrift, samt konfigurasjon av konto, oppsett av profil og vedlikehold av profil. ruker tar ut noen kvitteringer, verifiserer og korrigerer noen opplysninger og logger av. Prosessmandat: dministrasjon av egen bruker Input ruker med smarttelefon, etablert bruker med mobiltelefon. Output: Oppdatert informasjon ktiviteter Pålogging, oppdatering, betaling og belastning, transaksjoner og overføringer. Deltagere: ruker, Leverandørs nettsider, betalingsløsning, betalingssystem transaksjonssystem PROSESS Løsningen skal støtte prosessen dministrasjon av egen bruker på en fullt ut adekvat måte. eskriv grundig inkludert transaksjon PROSESS Løsningen skal støtte administrasjon av brukerprofiler. eskriv løsning. 3.4 Rapportering og kontroll rukstilfeller h): Revisor er på besøk og ønsker å se gjennom hele kontrollregimet knyttet til mobil billett.. lle rapporter blir gjennomgått, og avstemt mot banktransaksjoner, transaksjonslogger på billettnivå. lle tall stemmer og revisor sier seg fornøyd. rukstilfeller i): Ledelsen i TFT ønsker rapport på bruk av tjenesten. Tjenesteansvarlig hos Oppdragsgiver tar ut rapport, lager presentasjon som gir en god oversikt. Prosessmandat: Rapportering og kontroll Input Kontrollbehov og rapporteringsbehov, informasjonsbehov Output: Rapporter for avstemming i forhold til transaksjoner ktiviteter ruker går inn i systemet og velger eller konfigurerer rapporter og/eller utlasting av data. Deltagere: Kontroller, systemer PROSESS Løsningen skal gi støtte for rapportering og kontroll av transaksjoner, overføringer og bruk av systemet. eskriv utføring PROSESS Kontroll og avstemming skal tilfredsstille bokføringslovens krav, samt alle andre lovpålagte og forskriftspålagte krav. eskriv PROSESS Kontroll og avstemming skal bidra til å sikre løsningen mot svindel, samt gi sikkerhet i løsning, transaksjoner. Og alle ledd i verdikjeden. eskriv løsning PROSESS Kontroll og avstemming skal gi Oppdragsgiver daglige rapporter på bruk av systemet. eskriv løsning PROSESS Kontroll og avstemming skal gi Oppdragsgiver mulighet til å ta ut egendefinerte rapporter. Et minimum er antall salg pr produkt og kategori, salgsbeløp pr produkt og kategori, og at disse kan sammenlignes med tidligere egendefinerte perioder. eskriv løsning. Side 7 av 17

8 3.5 illettkontroll rukstilfeller j): Det er billettkontroll på en av byens busser. Kontrollørene har med seg utstyr, kontrollerer alle reisende. lant de reisende er det noen med mobil billett. Kontrollørene kontrollerer billetten, og finner alle unntatt to å være gyldige. En av disse har tilsynelatende gyldig billett, men animasjon av QR koden avdekker at dette er svindel.- Første blir ilagt gebyr for manglende billett, mens andremann blir anmeldt til politiet for forsøk på svindel. rukstilfeller k) : Klikker på illett -fanen og tar opp gjeldende billett. Kommentar: illetten ligger lokalt i applikasjonen for å være uavhengig av nettilgang. Dersom kunden kun har én billett vises denne. Dersom kunden har flere billetter velger kunden billett fra en liste. illettene er listet i rekkefølge basert på tid hvor nærmeste reise vises først. I illett -fanen ligger også ev. utgåtte billetter. Utgåtte billetter kan manuelt fjernes, ev. skjer fjerning automatisk etter parametere satt av TFT. Enkeltbilletter skal kunne merkes som brukt, dvs. ikke kan brukes av annen reisende. Prosessmandat: illettkontroll. Input Kontrollører, og brukere med mobiltelefon. Output: Kontrollerte billetter, ilagte gebyrer. ktiviteter ruker går inn i systemet og velger eller konfigurerer rapporter og/eller utlasting av data. Deltagere: Kontroller, systemer PROSESS Løsningen skal beskrive hvordan kontrollører skal kunne kontrollere billetter med QR koder PROSESS Løsningen skal beskrive hvordan kontrollørene skal kunne validere QR koder PROSESS Løsningen skal beskrive hvordan man sikrer at QR- koden er riktig. 4 Funksjonelle krav 4.1 rukeropplevelse En god brukeropplevelse er viktig for at de reisende tar løsningen i bruk. Da kjøp ofte skjer mens brukeren er på farten og i svært ulike miljøer, er det viktig at løsningen raskt gir brukeren tilgang til ønsket funksjonalitet. rukeropplevelsen skapes av samspillet mellom alle kanalene brukeren møter, og løsningen må ses i sammenheng med TFT sine øvrige brukergrensesnitt FUNK Løsningen må være enkel å ta i bruk for nye brukere FUNK Løsningen må gi mulighet til å kjøpe mobilbillett uten å måtte registrere seg i forkant. eskriv løsning FUNK Interaksjonsdesignet skal gi så høy ytelse, effektiv bruk og kort responstid FUNK Utstrakt bruk av ikoner/piktogrammer for rask gjenkjennelse er ønskelig. C FUNK Mulighet for å gjøre personlige preferanser skal støttes. Eksempelvis ved å kunne repetere tidligere kjøp, lagre informasjon om betalingsmåte, billettype og min reisestrekning/mine soner. Side 8 av 17

9 4.2 Grafisk utforming TFT har ikke egne retningslinjer for design på mobil. På grunn av skjermstørrelse, interaksjonsform og brukssituasjon vil ikke TFT sin designstandard nødvendigvis kunne overføres direkte, men elementer herfra skal i størst mulig grad benyttes. Designmanual for TFT ligger ved denne kravspesifikasjonen FUNK Ikoner og tekst skal være tydelige med god kontrast slik at det er lett å se elementene FUNK Elementer må ha konsistent plassering iht. anerkjent praksis for tilsvarende mobilapplikasjoner, styleguides og lignende FUNK Fargebruken må være konsistent og i henhold til TFT sin visuelle profil FUNK Små berøringsskjermer tilsier god plass mellom elementene slik at brukeren C klarer å velge ønsket element FUNK Designet skal så langt det lar seg gjøre følge operativsystemets designmetode og brukergrensesnitt uten å gå på bekostning av brukeropplevelsen FUNK ruk av logo m.m. skal ikke gå ut over ytelse FUNK pplikasjonen må kunne endres på et senere tidspunkt dersom TFT gjør endringer i sin design eller grafiske profil. 4.3 Universell utforming FUNK Så langt det er mulig og hensiktsmessig skal tilbudt løsning ta hensyn til gjeldende krav om universell utforming for brukere med syns- og/eller annen funksjonshemming. eskriv løsning. 4.4 Personvern Løsningen vil kunne inneholde personopplysninger. Kunden skal ved installasjon av app få informasjon om hvordan appen håndterer personopplysninger i pp Store og ndroid Marked, og kvittere ut dette før installasjon kan gjøres. Se I tillegg til ordinær lovgivning på området er det etablert en ny bransjenorm for anonyme reiser: FUNK Løsningen skal støtte den nye bransjenormen for e-billettering FUNK Løsningen skal etterleve norsk personvernlovgivning. eskriv løsning. 4.5 Sikkerhet For å sikre at informasjon og tjenester ikke blir misbrukt må leverandør beskrive sikkerheten i løsningen. Spesielt gjelder dette datasikkerhet (eksempelvis sikker lagring av nødvendig data lokalt i applikasjonen og sikker overføring av data mellom forskjellige systemer), sikkerhet mot svindel og snik (eksempelvis system for å hindre videresending av mobilbilletter mellom forskjellige mobiltelefoner). Ev. øvrige sikkerhetsaspekter skal også beskrives FUNK Løsningen skal sikre data mot uautorisert manipulering og innsyn. eskriv løsning FUNK Løsningen skal sikre mot svindel. eskriv løsning FUNK Løsningen skal sikre mot snik. eskriv løsning FUNK Leverandør skal beskrive risiko i løsning og tjeneste sammen med tiltak og kontrollmekanismer for å adressere disse.. Side 9 av 17

10 4.6 Krav til billetten pplikasjonens billetter skal leveres i form av QR-kode og animasjon, i tillegg til nødvendige metadata om billetten som er lesbare for NOD Klienten (NOD=«Nasjonal Ordredatabase»). Detaljerte krav og utfyllende informasjon finnes i H206 Del 25 som vil bli utlevert på forespørsel fra Tilbyder. Oppdragsgiver vil stille som krav for aksept av leveransen at samsvar med H206 del 25 dokumenteres gjennom nødvendige tester, inklusive avlesning og verifikasjon av innhold i QR-kode ved bruk av avlesningsutstyr fra tredjepart. Oppdragsgiver gjør oppmerksom på at nøkler og animasjoner til bruk i samsvar med H206 del 25 leveres av Interoperabilitetstjenester S. a) Tilbyder kan legge til grunn for sitt tilbud at Oppdragsgiver vil stille til rådighet kostnadsfrie webtjenester som returnerer QR-kode og animasjon iht krav i H206 del 25. Dette gjøres via systemet NOD i tråd med egne NOD-kliengrensesnitt spesifisert i H206 del 22 som vil bli utlevert på forespørsel fra Tilbyder. rbeidet med å tilrettelegge for uthenting via NOD må prises inn i tilbudet. Se vedlegg "NOD Client Development" for en generell beskrivelse av utvikling av NOD Klienter. b) Som alternativ til a) kan tilbyder velge å benytte annen metode for generering og levering av QRkode, animasjoner og andre støttetjenester. Ved valg av dette alternativet påtar Tilbyder seg ansvaret for at Leveransen er i samsvar med krav i H206 del 25. rbeid med planlegging, gjennomføring og eventuelle gjentatte tester i forkant av Oppdragsgivers aksept av leveransen må prises inn i tilbudet FUNK illetten skal være visuelt lesbar med tekst og symboler FUNK illetten skal inneholde TFT sin logo FUNK illetten skal inneholde en maskinelt lesbar QR-kode i henhold til Vegvesenets Håndbok 206 standard. eskriv hvordan dette er løst FUNK illetten skal inneholde tekst med informasjon om billettkategori og gyldighetstid FUNK illetten skal inneholde sikkerhetsanimasjon for visuell kontroll og visning av utløpte billetter FUNK illetten skal inneholde en nedtellingsfunksjon (animasjon) som viser gjenværende gyldighetstid og en label/stempel som legger seg over billetten inkludert QR-koden for ugyldig/utløpt billett FUNK illetten skal være mulig å verifisere for våre kontrollører gjennom lesning av QR-kode. eskriv løsning FUNK illett leveres automatisk 2 minutter etter at betaling er fullført. illettleveransen fungerer også som kvittering på billettkjøpet. Tidsforsinkelsen må være konfigurerbar. Det må gis informasjon om levering av billett til telefonen rett etter kjøpet FUNK Løsningen må inneholde funksjonalitet som muliggjør utskrift av kvittering på papir, for eksempel gjennom å lage en billettkvittering som sendes på e-post fra mobiltelefonen sin standard epostklient eller utsendelse av kvitteringer fra leverandørens produksjonsmiljø. 4.7 Rapportering og kontroll Statistikkmuligheter for å registrere nedlastning av applikasjonen samt salgs- bruksmønster skal beskrives. Rapporter for salg av reiseprodukter som støtter gjeldende regnskapskrav må genereres fortløpende FUNK TFT skal ha overført daglig transaksjonslogg som inneholder alle transaksjoner mot kunder Side 10 av 17

11 4.7.2 FUNK Systemet må tilfredsstille norsk regnskapslovgivning, forskrifter, standarder og normer FUNK Systemet må ha støtte for å kunne dokumentere alle steg i transaksjonsprosessene for kontroll blant annet for å avgjøre hvorvidt en kunde har blitt belastet eller ikke, betaling gjennomført eller ikke, og hvorvidt kunden har fått utstedt og overført billett mv FUNK Transaksjonsloggen må være på norsk FUNK Løsningen skal inneholde en rapporteringsløsning der TFT kan ta ut rapporter om bruk. eskriv standardrapporter, funksjonalitet og bruk. 5 Teknologiske krav mobil applikasjon Løsningen skal gjøres tilgjengelig på følgende mobiltelefonplattformer: 5.1 TEK Løsningen skal gjøres tilgjengelig på iphone versjon 4.0 og nyere, samt ndroid versjon 2,2 eller nyere. Dersom løsningen ikke skal støtte nevnte og nyere versjoner skal dette begrunnes i tilbudet 5.2 TEK pplikasjonene skal benytte de underliggende plattformenes standarder for brukergrensesnitt og navigasjon. 5.3 TEK pplikasjoner skal støtte stående format hvor høyden på skjermen er større enn bredden. 5.4 TEK For enheter med mulighet for skjermrotasjon bør løsningen også støtte liggende format. 5.5 TEK pplikasjonene kjøres på forskjellige typer mobiltelefoner med forskjellige skjermstørrelser. pplikasjonene må derfor utvikles slik at brukergrensesnittet tilpasser seg mobiltelefonens skjerm. 5.6 TEK De mest populære skjermoppløsninger skal støttes som et minimum. Disse skal beskrives med begrunnelse i tilbudet. 5.7 TEK ntall piksler pr. centimeter vil variere fra telefon til telefon. pplikasjoner må utarbeides slik at den tilpasser seg og utnytter høy pikseltetthet. illedbruk må optimaliseres for mobil bruk og bør ikke gå på bekostning av ytelse. 5.8 TEK pplikasjonene skal lages slik at de kan benyttes ved hjelp av berøringsfølsomme skjermer. 5.9 TEK pplikasjonene skal støtte norsk språk i ledetekster og innhold TEK pplikasjonene bør støtte engelsk språk i ledetekster og innhold. pplikasjonen skal tilpasse seg språkinnstillinger på telefonen.. Side 11 av 17

12 6 etalingsløsning Løsningen skal i første omgang støtte betaling fra kredittkort, mobil reisekonto og via telefonregning. Løsning må ta høyde for at annen betalingsformidler kan benyttes ved et senere tidspunkt. 6.1 ETL Det skal være mulig å betale billett ved hjelp av kredittkort, mobil reisekonto eller telefonregning. 6.2 ETL De mest utbredte kredittkorttypene i det norske markedet skal støttes, minimum Mastercard og Visa. 6.4 ETL Det skal være mulig å kjøpe billetter og benytte tidligere definerte betalingsmåter og betalingsdetaljer. eskriv løsning og sikkerhet i denne. 6.5 ETL illettløsning og betalingsløsning skal dekke ulike brukergrupper behov, rammebetingelser og forutsetninger blant disse barn, ungdom, voksne, eldre og funksjonshemmede. eskriv løsning. 7 Opsjoner Sonetilhørighet ses gjerne definert ved hjelp av posisjonering (GPS-koordinater) eller på bakgrunn av brukerprofil. Som hjelp til å finne min(e) sone(r) kan ev. stoppested/adressesøk benyttes. Om man ønsker å avbryte eller gå tilbake til foregående steg, bør dette løses intuitivt for kunden. 7.1 Fra og til, samt sonetilhørighet På sikt kan det bli krav om at man skal kunne velge reisestrekning direkte eller indirekte og betale en billett i henhold til reisesoner. Holdeplasser for buss og hurtigbåt er i ulike soner. åt, buss og ferge har ulike pristabeller / takstregulativer OPSJON Løsningen bør kunne støtte reise mellom ulike holdeplasser på en brukervennlig måte. eskriv løsning og muligheter OPSJON Løsningen må kunne håndtere billettpriser basert på antallet soner man reiser. eskriv muligheter, forutsetninger og løsning OPSJON Sonetilhørighet bør kunne defineres ut fra GPS. eskriv løsning. 7.2 Videreutvikling og endring VIENDR Leverandør skal støtte change management og endringer av selve applikasjonen i forhold til endrede krav mv. eskriv planer, muligheter og eventuelle tilpasninger. Side 12 av 17

13 8 Krav til drift og forvaltning Det er et formål med etablering av tjenesten at kjøp av billett skal være en tilgjengelig for TFT sine brukere når de skal reise med buss, båt og ferge, og tjenesten skal være driftssikker, robust og pålitelig. 8.1 Generelle krav til drift DRIFT Tjenesten skal driftes i et definert produksjonsmiljø, som kun inneholder systemer som er i operativ drift. Driftsmiljøet skal være adskilt fra test og utviklingsmiljøer DRIFT Systemet skal være operativt med døgnkontinuerlig drift slik at det er mulig å kjøpe mobil billett 24 timer i døgnet alle dager i uken eventuelt med unntak av definerte servicevindu. Servicevindu skal være innen et definert tidsintervall når det ikke går busser i Troms DRIFT Tjenesten skal ha en definert oppetid på mer enn 99,7 %. Tjenestekatalogen skal angi forpliktende oppetid og beregningsformel for disse DRIFT Leverandøren skal ha et separat testmiljø for uttesting av nye versjoner DRIFT Oppetidsrapportering: Leverandøren skal fortløpende måle oppetid og tilgjengelighet for tjenesten målt fra utsiden av Leverandørens driftsmiljø og rapportere dette til Oppdragsgiver. eskriv løsning og rapporteringsmodell DRIFT Responstidsmåling: Leverandøren skal foreta jevnlig måling av responstid for å sikre god kvalitet for brukerne, og rapportere denne. eskriv metode og hyppighet DRIFT Servicedesk: Leverandør skal tilby andrelinje service. eskriv servicemål DRIFT Servicedesk. Leverandør skal tilby førstelinje service for bruker av løsningen med fokus på betalingsløsning og transaksjoner. eskriv servicenivå, responstider og kapasitet samt kompetanse DRIFT eredskap og katastrofeplaner: Leverandøren skal ha beredskap og katastrofeplaner med alternativ driftsløsning som sikrer kontinuerlig drift dersom leverandørens driftsmiljø helt eller delvis settes ut av produksjon, gjøres utilgjengelig eller på annen måte gjøres utilgjengelig. 8.2 Krav til driftsprosesser og samhandling Vellykket etablering og drift av tjenesten forutsetter god kvalitet i sine driftsoperasjoner og god samhandling mellom Oppdragsgiver og Leverandør. Leverandøren må kunne dokumentere og beskrive sine prosesser. ITIL er et anerkjent rammeverk for dette, og Oppdragsgiver legger til grunn ITIL som driftsmodell for hele tjenesten. Dersom leverandøren benytter et annet anerkjent rammeverk så skal dette beskriver og dokumenteres PROSSM Konfigurasjonsstyring: Leverandøren skal ha en definert og dokumentert konfigurasjonsstyringsprosess som baserer seg på ITIL rammeverket og som sikrer at leverandøren har kontroll på alle komponenter og elementer i tjenesten. eskriv prosess med roller, aktiviteter, dokumentasjon og Oppdragsgivers involvering PROSSM Hendelsesstyring. (Incident management): Leverandøren skal ha en definert hendelsesstyringsprosess basert på ITIL rammeverket som sikrer at leverandøren har kontroll på og håndterer alle uforutsette hendelser. eskriv prosess med roller, aktiviteter, dokumentasjon og Oppdragsgivers involvering PROSSM Hendelsesstyringen skal sørge for at å reetablere tjenesten etter en hendelse uten tap av data, og med minimal påvirkning for brukerne PROSSM Hendelsesstyringen skal ha en prosess som prioriterer hendelser ut fra deres viktighet. Side 13 av 17

14 8.2.5 PROSSM Hendelsesstyringen skal sikre umiddelbar rapportering til Kunden ved alvorlige avvik og daglig og ukentlig rapportering av hendelser PROSSM Problem Management: Leverandøren skal ha en definert prosess for Problem Management basert på ITIL rammeverket og som sikrer at leverandøren kan løse problemer og kan rette disse. eskriv prosess med roller, aktiviteter, dokumentasjon og Oppdragsgivers involvering PROSSM Endringsstyring. (Change Management): Leverandøren skal ha en definert prosess for endringsstyring basert på ITIL rammeverket og som sikrer at leverandøren har kontroll på og endringer og endringsforslag. eskriv prosess med roller, aktiviteter, dokumentasjon og Oppdragsgivers involvering PROSSM Kontinuitetsstyring (Continuity Management): Leverandøren skal ha en definert kontinuitetsplan basert på ITIL rammeverket og som sikrer kontinuitet i tjenesten. eskriv prosess med roller, aktiviteter, dokumentasjon og Oppdragsgivers involvering PROSSM ackup og Recovery: Leverandøren skal ha dokumenterte prosesser for backup og recovery av data, og disse skal testes med definerte tidsintervaller PROSSM Oppdateringer (Release Management): Leverandøren skal ha en definert prosess for oppdateringer basert på ITIL rammeverket og som sikrer utrulling og produksjonsstart på en sikker og kontrollert måte. eskriv prosess med roller, aktiviteter, dokumentasjon og Oppdragsgivers involvering PROSSM Service Level Management: Leverandøren skal ha en definert prosess for å sikre at tjenesten leveres i henhold til inngåtte avtaler (Service Level management) basert på ITIL, som sikrer god styring, samsvar med lover og forskrifter, rammeverket. eskriv prosess med roller, aktiviteter, dokumentasjon og Oppdragsgivers involvering PROSSM Prosjektmøter: I etableringsfasen skal det være jevnlige prosjektmøter der de som har det operative ansvaret for etableringen innen de ulike områdene deltar sammen med prosjektdeltagere ut fra behov PROSSM Driftsmøter: I driftsfasen skal det være jevnlige driftsmøter der de som har det operative ansvaret for driften deltar sammen med annet personale ut fra behov. Møtene skal ta opp alle vesentlige forhold til driften og PROSSM Styringsgruppe: åde Etableringsprosjektet og Tjenesten skal ha en styringsgruppe som møtes jevnlig. 9 Etableringsprosjekt Det skal gjennomføres et etableringsprosjekt for løsning. 9.1 PROSJEKT Det skal gjennomføres et etableringsprosjekt. Leverandøren skal beskrive gjennomføringen av dette basert på kontraktens bestemmelser, god praksis og de enkeltelementer som er beskrevet under. 9.2 PROSJEKT Oppdragsgiver skal delta i design og utforming av løsning og prosesser så langt disse skal tilpasses. 9.3 PROSJEKT Leverandør skal ha en dedikert prosjektleder som er ansvarlig for Leverandørens leveranser. 9.4 PROSJEKT Prosjektet skal gjennomføre risikostyring. 9.5 PROSJEKT Prosjektet skal rapportere progresjon en gang pr uke. 9.6 PROSJEKT Det skal leveres en plan på gjennomføring av prosjektet ved oppstart. 9.7 PROSJEKT Leverandøren skal gjennomføre egen testing og testrapport med oversikt over alle avdekte de feil med status skal leveres til Oppdragsgiver ved tilgjengeliggjøring for oppdragsgiver. Side 14 av 17

15 9.8 PROSJEKT Prosjektet skal ha en definert og tydeligovergang til produksjon med en definert oppstartsfase. 9.9 PROSJEKT TFT skal ha full råderett over markedsføring og tilgjengeliggjøring av app PROSJEKT Overlevering fra drift til produksjon skal gjøres i henhold til adekvate ITILprosesser og leverandørens implementering av slike PROSJEKT Prosjektet skal gjennomføre en pilotfase. rukertester skal gjøres i denne fasen PROSJEKT Leverandør skal sørge for tilstrekkelig opplæring av alle funksjoner knyttet til salg og de data som genereres som følge av bruk av appen. Inkluderer opplæring av avvikshandtering, rapportering og dokumentasjon. Side 15 av 17

16 10 Produkter mobil billettering Troms Generelt: Løsningen skal kunne brukes på buss, båt og ferge i Troms fylke. rukeren skal kunne ha sin individuelle favorittbillett. I tillegg skal brukeren enkelt kunne nå alle billetter i løsningen. Det skal også kunne brukes på fylkeskryssende produkter og samarbeidsløsninger med Nordland og Finnmark fylker. Dersom oppdragsgiver ønsker å deaktivere billetter, skal dette kunne gjøres i løsningen slik at kunden ikke kan se eller kjøpe dem. Dette skal kunne gjøres uten tilleggskostnad for oppdragsgiver dersom leverandøren må utføre deaktiveringen. Tilsvarende gjelder for aktivering av deaktiverte billetter. I første omgang er det buss i bysonen Tromsø (sone se Systemet skal takle utvidelser av sonegyldighet, dvs. flere soner. Forkortelser kundekategorier: V = Voksen = arn H = Honnør U = Ungdom UV = Ung/Voksen 1. Overordnet produktfunksjonalitet V10.1 PRODUKT Kunden skal kunne velge sitt favorittprodukt (default). Favorittproduktet skal dukke opp på startsiden for kunden. Kunden skal enkelt kunne velge andre produkter for tilfeldige reiser V10.2 PRODUKT Produktsalg skal kunne inneholde flere produkter og med ulike kombinasjoner av kundekategorier. V10.3 PRODUKT Systemet skal takle utvidelser av antall billetter og kategorier 1.1 illetter buss V PRODUKT Enkeltbillett Tromsø Enkeltbillett 1 sone Troms Kundekat: V,, H V PRODUKT Periodebillett 30 dager Kundekat: V,, H, U, UV illetten må kunne lastes inn kostnadsfritt i annen telefon (dersom kunden f.eks. mister telefonen) V PRODUKT 24 timers billett Tromsø Kundekat: V, 24 timers billett 1 sone Troms Kundekat: V, V PRODUKT Eventbilletter (definisjoner etter avtale) 1.2 illetter båt V PRODUKT Enkeltbillett Tromsø-Finnsnes Enkeltbillett Finnsnes-Tromsø Enkeltbillett Tromsø-Harstad Enkeltbillett Harstad-Tromsø Kundekat: V,, H V PRODUKT Eventbilletter Side 16 av 17

17 1.3 illetter ferge V PRODUKT Enkeltbillett reivikeidet-svensby Enkeltbillett Svensby-reivikeidet Enkeltbillett Lyngseidet-Olderdalen Enkeltbillett Olderdalen-Lyngseidet Kundekat: V,, H V PRODUKT il < 6m inkl. fører reivikeidet-svensby il < 6m inkl. fører Svensby-reivikeidet il < 6m inkl. fører Lyngseidet-Olderdalen il < 6m inkl. fører Olderdalen-Lyngseidet V PRODUKT Eventbilletter V OPSJON Flere fergestrekninger Side 17 av 17