Bilag 1 Kravspesifikasjon Mobilbillett 2014.

Transkript

1 Bilag 1 spesifikasjon Mobilbillett Innledning Dagens billettsystem er basert på et sonesystem som pr. i dag omfatter 136 soner som gjenspeiler takstsystemet. Det pågår for tiden et prosjekt som har som mål å revidere takstog sonestrukturen, og et overordnet mål er å redusere antall soner vesentlig. Sannsynligvis blir resultatet en reduksjon til 4 eller 26 soner med tilhørende takstgruppe. Dette forenklede sonesystemet vil sannsynligvis være klart å tas i bruk 1. januar Fra kontraktsoppstart frem til ny sonestruktur er på plass, skal appen fungere med den sonestruktur som er gjeldende pr. i dag, og som er beskrevet i dette dokument. spesifikasjonen stiller funksjonelle krav til appen og løsningen som sådan. ene fremkommer i tabellform som obligatoriske (O), valgfrie (V) og en avkrysningsdel for tilbyder (T). Det er meget viktig at tilbyder krysser av i alle tabellene i kravspesifikasjonen, og returnerer i utfylt stand sammen med sitt tilbud. Tilbyders meroppfyllelse her vil inngå som en del av evalueringen under tildelingskriteriet «Kvalitet», jfr. konkurransegrunnlaget pkt. 4. Hver punktvise meroppfyllelse belønnes med ett poeng. Overordnede krav Leverandøren skal tilby en helhetlig og komplett systemløsning for salg av billetter via mobile applikasjoner på smarttelefoner. Appen skal være klar til å tas i bruk senest 1. sept Evt. utviklingsdel av leveransen skal ikke overstige kjøpsdelen av leveransen hverken i omfang eller i pris. Oppdragsgiver poengterer at løsningen (appen) skal være et produkt som er klar til operativ bruk. Oppdragsgiver gjør oppmerksom på at evt. utvikling kun skal bestå av mindre tilpasninger til system, profil m.v., og evt. innsats fra oppdragsgiver begrenser seg til mindre omfattende brukstesting, profil- og lay out-relatert bistand. Løsningen må være enkel å ta i bruk. Kjøpte billetter skal være tilgjengelige uten tilgang på internett, og appen må kunne laste ned et sett med animasjoner (eks. 7 kommende dager) slik at billetten som blir aktivert vil ha tilgjengelig dagens animasjon. Mulighet for å gjøre personlige preferanser skal støttes. Eksempelvis ved å kunne repetere tidligere kjøp, lagre informasjon om betalingsmåte, billettype og favorittreiser (reisestrekning / soner). Universell utforming må ivaretas. Ikoner og tekst skal være tydelige med god kontrast slik at det er lett å se elementene. Tilbudt løsning må etterleve personvernbestemmelsene i personopplysningsloven, og sikre retten til anonyme reiser, jfr. felles bransjenorm for kollektivtrafikkbransjen:

2 Appen skal fungere på de vanligste smartmobil-os i markedet, med senere oppgraderinger av OS, og tilbudt løsning skal kunne tilpasses / videreutvikles slik at overgang til kjøp og bruk av mobilbillett ved NFC er mulig. Appens billetter skal inneholde QR-kode og animasjon, i tillegg til nødvendige metadata om billetten som er lesbare for NOD-Klienten (NOD=«Nasjonal Ordredatabase») i henhold til Statens Vegvesen håndbok 206. Håndbok 206 elektronisk billettering ligger tilgjengelig på Statens Vegvesen sine nettsider på følgende adresse: NOD-klientgrensesnitt er spesifisert i håndbok 206 del 22 (Vedlegg B og D er underlagt restriksjoner, og bestilles hos publvd@vegvesen.no ). Billetten skal inneholde en maskinelt lesbar QR-kode i henhold til håndbok 206 standard. Kolumbus vil stille som krav for aksept av leveransen at samsvar med håndbok 206 del 25 dokumenteres gjennom nødvendige tester, inklusive avlesning og verifikasjon av innhold i QR-kode ved bruk av avlesningsutstyr fra tredjepart. Kolumbus gjør oppmerksom på at nøkler og animasjoner til bruk i samsvar med håndbok 206 del 25 leveres av Interoperabilitetstjenester AS. 1. Generelle krav til løsningen 1.1 Brukeropplevelse En god brukeropplevelse er viktig for at de reisende tar løsningen i bruk. Da kjøp ofte skjer mens brukeren er på farten, er det viktig at løsningen raskt gir brukeren tilgang til ønsket funksjonalitet. Brukeropplevelsen skapes av samspillet mellom alle kanalene brukeren møter, og løsningen må ses i sammenheng med Kolumbus øvrige brukergrensesnitt. Spesielt gjelder dette kolumbus.no hvor komplementære tjenester som for eksempel registrering av evt. brukerprofil skal kunne utføres. 1.2 Brukervennlighet Løsningen må være enkel å ta i bruk for nye brukere, og mulighet til å kjøpe mobilbillett uten å måtte registrere seg i forkant av kjøpet skal beskrives. Interaksjonsdesignet skal gi så høy ytelse og så kort responstid som mulig. Utstrakt bruk av ikoner / piktogrammer for rask gjenkjennelse er ønskelig. Mulighet for å gjøre personlige tilpasninger skal støttes. Eksempelvis ved å lagre informasjon om betalingsmåte, billettype og min reisestrekning / mine soner.

3 1.3 Grafisk utforming Ikoner og tekst skal være tydelige med god kontrast slik at det er lett å se elementene. Elementer må ha konsistent plassering iht. interaksjonsdesignkonvensjoner. Fargebruken må være konsistent og i henhold til Kolumbus visuelle profil. Små berøringsskjermer tilsier god plass mellom elementene slik at brukeren klarer å velge ønsket element. Designet skal så langt det lar seg gjøre følge operativsystemets designmetode og brukergrensesnitt uten å gå på bekostning av brukeropplevelsen. Bruk av logo m.m. skal ikke gå ut over ytelse. 1.4 Universell utforming Tilbudt løsning skal ta hensyn til gjeldende krav om universell utforming for brukere med syns- og/eller annen funksjonshemming, jfr. Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger av 21. juni Personvern Tilbudt løsning må etterleve personvernbestemmelsene i den nye bransjenormen som skal sikre anonyme kollektivreiser. Appen skal ha en personvernerklæring som kunden er nødt til å lese og kvittere ut som akseptert for å ta appen i bruk. Denne personvernerklæringen skal også kunne tas frem igjen fra menyen i appen ved senere anledninger. Se:

4 1.6 Sikkerhet For å sikre at informasjon og tjenester ikke blir misbrukt, må leverandør beskrive en plan for sikkerhet 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) og snik (eksempelvis system for å hindre videresending av mobilbilletter mellom forskjellige mobiltelefoner). Evt. øvrige sikkerhetsaspekter skal også beskrives. En gjennomgang av sikkerheten kan bli gjort sammen med en uavhengig part innledningsvis i prosjektet. 1.7 til billetten Billetten skal inneholde maskinelt lesbar QR-kode i tillegg til vanlig tekst med informasjon om blant annet billettkategori og gyldighetstid samt sikkerhetsanimasjon (evt. annen sikkerhetsløsning) for visuell kontroll. QR-kode og animasjon skal innfri kravene i Håndbok 206 (Statens Vegvesen). Tekniske krav til animasjon: PNG-format, 100 x 100 piksler farge 3 bytes RGB fargekoder, fadehastighet animasjon: 0,4s, 1,0s, 1,6s eller 2,2s. For å unngå svindel, bør ikke QR-kode / animasjon være synlig før billetten kan valideres. Det skal være en forsinkelse på 2-5 min fra kjøp til levering for å redusere risiko for snik. Billetten skal være tilgjengelig også i offlinemodus slik at det er mulig å kontrollere billetten også i de tilfeller hvor brukeren ikke har mobil- eller WiFi-dekning. Tilleggsbillett utvider sonen. Ingen forsinkelse fra kjøp til gyldighet. Billetten må automatisk gjøres om til Dagpass ved kjøp over fem soner. 1.8 Billettype Det skal være mulig å kjøpe følgende Kolumbus billettyper i løsningen: Enkeltbillett buss Enkeltbillett båt Periodepass båt Periodepass buss / tog Kombipass Flexipass Ungdomspass Studentpass Dag- og korttidspass Nærmere produktbeskrivelse finnes på

5 1.9 Mobilkonto Det er et krav at brukeren kan opprette en mobilkonto hvor brukeren fyller på penger ved hjelp av løsningens standard betalingsmåte(r). Mobilkonto kan brukes til å betale for egne billetter med, men spesielt viktig er muligheten til å knytte flere brukere sammen. En bruker, for eksempel en foresatt, skal kunne gi tilgang til en eller flere andre brukere, for eksempel sitt barn, til sin mobilkonto. De(n) andre brukeren/ne kan deretter kjøpe billetter og betale med denne mobilkontoen. Knytningen mellom brukere og mobilkontoer skal være enkel, sikker og intuitiv. Slik kan et barn uten egne betalingsmetoder kjøpe billetter uten å få tilgang til foreldrenes betalingskort. Leverandøren bes også beskrive alternative måter å fylle opp mobilkontoen på, slik at en bedrift ved hjelp av betaling i skranke hos Kolumbus eller ved hjelp av bankoverføring kan fylle opp en mobilkonto og gjøre denne tilgjengelig for en eller flere av sine ansatte Rapportering Reiser. Det skal være enkelt for Kolumbus å hente ut statistikk over antall solgte billetter og omsetning, begge fordelt på periode. Rapporten skal vise statistikk fordelt på dag, uke, måned og år. Billettype (produkt) skal tydelig fremgå av statistikken. Oppdragsgiver skal kunne hente ut statistikk fordelt på holdeplass, og sone. Dette gjelder både påstigning og avstigning. Løsningen skal tilby eget datavarehus Regnskap, økonomi. Løsningen skal innfri de til enhver tid gjeldende krav i lovgivningen til regnskaps- og økonomirapporter, herunder kontrollmuligheter for uavhengig tredjepart typisk revisor. Løsningen skal muliggjør avstemming mot innløserenhet Min side Kolumbus ser det som en fordel om brukeren kan administrere sin bruker / konto, fylle på penger, knytte sammen brukere m.v. i et mer funksjonsrikt grensesnitt slik som nettleser på PC eller Mac. Som en del av løsningen bør derfor leverandøren tilby et grensesnitt (som en nettside hvor brukeren kan logge inn). Leverandøren bes beskrive denne delen av løsningen, med fokus på bl.a. nettleserstøtte,responsiv tilpasning m.v.

6 1.12 Ny teknologi Det vil i løpet av 2014 sannsynligvis skje en utvikling av mobil billettering basert på NFC-teknologien. Tilbudt løsning skal kunne tilpasses/videreutvikles slik at blant annet sømløs overgang til mobilbillett på NFC-plattformen sikres. 2. elle og tekniske krav 2.1 Plattform Løsningen skal tilbys til de mobile operativsystemene Windows Phone 8, Android og ios. For Windows Phone 8 skal appen takle overgang til den varslede oppdateringen kjent som Windows Phone 8.1 (estimert til april 2014) uten ekstra kostnad for oppdragsgiver. For Android skal appen fungere for versjon 4.4 Kit Kat med runtime ART. Appen skal også være fullt ut bakoverkompatibel til Android versjon 4.1 med Dalvik runtime. For ios skal appen ved oppstart fungere på ios-enheter med ios 7.1. Appen skal også være fullt ut bakoverkompatibel til ios Skjermrotasjon Applikasjoner skal støtte stående format hvor høyden på skjermen er større enn bredden. For enheter med mulighet for skjermrotasjon bør løsningen utvikles for å støtte også liggende format. 2.3 Skjerm Appen skal ha god visning med bra lesbarhet på skjermstørrelser fra 4 tommer 6 tommer. Applikasjoner må utarbeides slik at høy pikseltetthet blir utnyttet maksimalt. Appen skal fungere på skjerm med oppløsning på 480 x 800 piksler (WVGA). Appen skal være optimalisert for visning på skjerm med høyere oppløsning enn 720 x 1280 piksler (WGA).

7 2.4 Berøringsskjerm Appen skal fungere på skjermer med kapasativ teknologi (berøringsskjerm). Ikoner som representerer valg i appen, f.eks. bekreftende valg som «kjøp», skal være store og tydelige nok til at det ikke er vanskelig og upresist å treffe med en normal voksen finger. 2.5 Språk Applikasjonene skal støtte både norsk og engelsk språk i ledetekster og innhold. Bruker skal selv kunne velge blant disse språkene. 2.6 Drift. Service. Oppetid. 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 på forhånd avtalte servicevindu. Servicevindu skal være innen et definert tidsintervall når aktuelle transportmidler i Kolumbus ikke er i drift. Oppetiden skal være på minimum 99 %. 3. Betalingsløsning Appen skal kunne gjennomføre transaksjoner via innløserbank, som f. eks. Teller e.l., som et nødvendig ledd i transaksjonsrekkefølgen. Leverandør skal være behjelpelig med konfigurasjon og avtaler mot betalingsintegrator og innløser. Kjøp av billett kan belastes brukerens mobilabonnement. Bruker skal kunne registrere kortopplysninger for de vanligste bankkort (f.eks. VISA og Mastercard) ved første betaling. Betalingsformidler lagrer disse opplysningene sikkert ihht. kortselskapenes retningslinjer.

8 4. Øvrig funksjonalitet Mobil arkitektur Løsningen bør skille presentasjon, datamodell og forretningslogikk. Leverandøren bes beskrive arkitekturen i løsningen og hvilke rammeverk og teknologier man ser for seg å benytte. Prosjektgjennomføring Leverandøren bes beskrive hvilke(t) verktøy som benyttes til støtte i prosjektgjennomføring som Kolumbus skal forholde seg til. Eksempel på dette kan være «Atlassian Jira versjon x med tilleggsmodulene Y og Z». Leverandøren bes også beskrive hvordan verktøyet benyttes og hvordan metodikk som brukes for gjennomføring av prosjektet. Generelle krav 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. Leverandøren skal ha et separat testmiljø som er tilgjengelig for Kolumbus. Servicedesk Leverandør skal tilby andrelinje service for Kolumbus egne ansatte som er involvert i løsningen. 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. 5. Opsjoner 5.1 Opsjon _1 Reiseplanlegger. Som opsjon bes leverandøren komme med tilbud og løsningsforslag for reiseplanlegger som en del av løsningen. Reiseplanleggeren skal gjøre det enkelt for brukeren å finne reisemåter mellom to forskjellige geografiske lokasjoner, adresser eller holdeplasser. Brukeren skal kunne se avgang, ankomst, reisetid og annen aktuell informasjon. Reiseplanleggeren bør kobles mot sanntidsdata for å gi brukeren presis informasjon om avganger og ankomst for reisen. Det bør også være mulig å se sanntidsdata for en valgt holdeplass uten å skulle planlegge reise. Kolumbus bruker Trapeze til håndtering av rutedata, og tilgjengeliggjør rutedata i REGTOPPformat. Leverandøren bør selv kunne legge inn oppdaterte REGTOPP-data i løsningen. Data kan også tilgjengeliggjøres i andre format. Leverandøren må da beskrive hvilket format som kreves. Sanntidsdata er tilgjengelig i henhold til SIRI-standarden (Service Interface for Real Time Information, europeisk standard CEN/TS 15531).

9 5.2 Opsjon_2 Skolekort Skoleelever som har rett til gratis skoleskyss har i dag egne skolekort. Det er ønskelig at det kan tilbys en egen funksjonalitet via mobilappen for de elevene som har rett på slik skyss. Vi ser her for oss at det etableres et administrasjonsgrensesnitt i løsningen hvor Kolumbus kan legge inn skolekort som pushes ut til de enkeltes brukeres telefoner. Det skal ikke være nødvendig å legge inn skolekort manuelt, dette må Kolumbus kunne importere i Excel eller annet format. Alternativt kan løsningen integreres direkte med Kolumbus system for håndtering av skoleskyss. Skolekortet skal tilfredsstille de krav som stilles til billett for øvrig. 5.3 Opsjon_3 Ansattkort Oppdragsgiver utsteder årskort til egne ansatte og sjåfører hos våre operatører. Dersom opsjonen utløses, ønskes mulighet til å legge inn ansattkort direkte i mobilen til den ansatte / sjåføren. En løsning hvor «kortet» pushes ut til mobilen, jfr. ovenfor under «Opsjon_2» er ønskelig. Løsningen skal tilfredsstille de krav som stilles til billett for øvrig.