Kravspesifikasjon Mobilbillett Innledning Dagens billettsystem er basert på et sonesystem som pr. i dag omfatter ca. 350 soner på buss i Nordland i 1-1 relasjon, og ca. 220 soner på båt i mange til mange relasjon som gjenspeiler dagens takstsystemet. I tillegg er det mange bussoner i Troms og Nord-Trøndelag som også billetteres. Som følge av økende frekvens i antall reisende er det ønskelig å fremskaffe et mobilt billetteringssystem (en applikasjon), med formål om å avlaste dagens billeteringsløsning, samt redusere tidsbruk ved ombordstigning. Kravspesifikasjonen stiller funksjonelle krav til applikasjonen og løsningen som sådan. Kravene fremkommer i tabellform som obligatoriske (), valgfrie (V) og har en svardel for tilbyder som fylles ut med «JA», «NEI» eller «DELVIS», avhengig av hvilken grad tilbudt løsning dekker kravene. Videre er et felt for løsningsbeskrivelse/dokumentasjon hvor løsning skal beskrives, eller hvor det skal henvises til annen dokumentasjon som beskriver løsningen. Det er meget viktig at tilbyder svarer i alle tabellene i kravspesifikasjonen, og dette returneres i utfylt stand sammen med tilbudet. verordnede krav Tilbyder skal tilby en helhetlig og komplett systemløsning for salg av billetter via mobile applikasjoner (app) på smarttelefoner. Appen skal være klar til å tas i bruk senest 16. desember. 2015. Eventuell utviklingsdel av leveransen skal ikke overstige kjøpsdelen av leveransen hverken i omfang eller i pris. ppdragsgiver poengterer at appen skal være et produkt som er klar til operativ bruk. ppdragsgiver 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: http://www.datatilsynet.no/global/04_veiledere/bransjenormer/bransjenorm_ebillettering_endelig_01.pdf
Appen skal fungere på is og Andriod, med senere oppgraderinger av S, og tilbudt løsning skal kunne tilpasses / videreutvikles slik at overgang til kjøp og bruk av mobilbillett ved NFC er mulig. Appen skal også kunne utvides til å gjelde Windows operativsystem jfr. psjon_2. Appens billetter skal inneholde QR-kode og animasjon, i tillegg til nødvendige metadata om billetten som er lesbare for ND-Klienten (ND=«Nasjonal rdredatabase») i henhold til Statens vegvesen håndbok 821. Håndbok 821 elektronisk billettering ligger tilgjengelig på Statens vegvesen sine nettsider på følgende adresse: http://www.vegvesen.no/fag/publikasjoner/handboker ND-klientgrensesnitt er spesifisert i håndbok 821 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 821 standard. ppdragsgiver vil stille som krav for aksept av leveransen at samsvar med håndbok 821 del 25 dokumenteres gjennom nødvendige tester, inklusive avlesning og verifikasjon av innhold i QR-kode ved bruk av avlesningsutstyr fra tredjepart. ppdragsgiver gjør oppmerksom på at nøkler og animasjoner til bruk i samsvar med håndbok 821 del 25 leveres av Interoperabilitetstjenester AS. Dersom det er elementer som er nødvendige for å etablere tjenesten med god kvalitet for oppdragsgiver skal disse tas med i tilbudt løsning. Dersom tilbyder ser 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 tilbyder påpeke dette og tilby løsning på disse. Tjenesten skal på en enkel måte beskrives med alle delkomponenter og sammenhengene mellom disse. Eventuelle avhengigheter til andre systemer og tjenster, samt forutsetninger til disse, skal beskrives. Ved levering av tilbud skal det foreligge en presentasjon av løsningen som dokumenterer funksjonalitet opp mot de krav som er satt i denne kravspesifikasjon. I tillegg en brukermanual med skjermdump som illustrerer bruk av applikasjon, og dertilhørende baksystem for rapportering og kontroll steg for steg. 1. Generelle krav til løsningen Nr Krav/funksjon Kat Svar Løsningsbeskrivelse/dokumentasjon 1.01 Tjenesten, systemet og applikasjonen skal tilfedstille, leveres og driftes i henhold til gjendelnde lover og forskrifter inkludert bokføringslov og regnskapslovgivning med forskrifter, samt normer og standarder. 1.02 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.
1.03 Løsningen skal være optimalisert på en slik måte at antall klikk tilknyttet et kjøp begrenses til det som kan anses å være et minimum, uten at det medfører redusert brukeropplevelse. 1.04 Applikasjon er tiltenkt salg av billetter i et begrenset område i og rundt Bodø by/sone 1. ppdragsgiver skal ha muligheten til å utvide applikasjon til å gjelde flere byer og/eller større områder ved et senere tidspunkt. Beskriv hvordan denne evt. utvidelsen vil løses. 1.06 Det er viktig for oppdragsgiver å vite fyllingsgrad på bussen, hvor ofte kundene reiser samt hvor kundene reiser. Systemet bør inneholde mekanismer som gir oss slik tillegsinformasjon. Eventuelt bes tilbyder forklare hva som kreves for å få slik informasjon. 1.07 Applikasjon skal være tilgjengelig i de vanligste distribusjonskanalene for sin plattform. 1.1 Brukervennlighet 1.08 Løsningen må være enkel å ta i bruk for nye brukere. Mulighet til å kjøpe mobilbillett uten å måtte registrere seg i forkant av kjøpet skal beskrives. 1.09 Interaksjonsdesignet skal gi så høy ytelse og så kort responstid som mulig. 1.10 Utstrakt bruk av ikoner/ piktogrammer for rask gjenkjennelse er påkrevd. 1.11 Mulighet for å gjøre personlige tilpasninger skal støttes. Eksempelvis ved å lagre informasjon om betalingsmåte og billettype. 1.2 Grafisk utforming 1.12 Ikoner og tekst skal være tydelige med god kontrast slik at
det er lett å se elementene. 1.13 Elementer må ha konsistent plassering iht. interaksjonsdesignkonvensjoner. 1.14 Fargebruken må være konsistent og i henhold til oppdragsgivers visuelle profil. 1.15 Små berøringsskjermer tilsier god plass mellom elementene slik at brukeren klarer å velge ønsket element. 1.16 Designet skal så langt det lar seg gjøre følge operativsystemets designmetode og brukergrensesnitt uten å gå på bekostning av brukeropplevelsen. 1.17 Bruk av logo m.m. skal ikke gå ut over ytelse V 1.3 Universell utforming 1.18 Tilbudt løsning skal følge 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 2013 1.4 Personvern 1.19 Tilbudt løsning må etterleve personvernbestemmelsene i den nye bransjenormen som skal sikre anonyme kollektivreiser. 1.20 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: http://www.datatilsynet.no/global/04_veiledere/bransjenormer/bransjenorm_ebillettering_endelig_01.pdf
1.5 Sikkerhet 1.21 For å sikre at informasjon og tjenester ikke blir misbrukt, må tilbyder beskrive en plan for sikkerhet i løsningen. Spesielt gjelder dette datasikkerhet (eks. sikker lagring av nødvendig data lokalt i app og sikker overføring av data mellom forskjellige systemer) og snik (eks. system for å hindre at billetter videresendes mellom mobiltelefoner.) Eventuelle øvrige sikkerhetsaspekter skal beskrives. En gjennomgang av sikkerheten kan bli gjennomført sammen med en uavhengig part innledningsvis i prosjektet. 1.6 Krav til billetten 1.22 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 821 (Statens vegvesen). Tekniske krav til animasjon: PNGformat, 100 x 100 piksler farge 3 bytes RGB fargekoder, fadehastighet animasjon: 0,4s, 1,0s, 1,6s eller 2,2s. 1.23 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. 1.24 Billetten skal være tilgjengelig også i offlinemodus slik at det er mulig å kontrollere billetten også i de tilfeller hvor brukeren ikke har mobileller WiFi-dekning. V
1.25 Løsningen skal gi mulighet for utskrift av kvittering/billett som dekker kravene i forhold til bokføring og reiseregninger (krav til salgsdokument). 1.26 Løsningen skal gi mulighet til forhåndskjøp av billetter i tilfeller der det er dårlig dekning på nett eller mobilnett. 1.27 Løsningen skal ha en kontrollørapp for å kunne validere QR koder. 1.7 Billettype 1.28 Det skal være mulig å kjøpe følgende billettyper: Enkeltbillett buss - Barn og honnør/ voksen/ung voksen Periodebillett buss - Barn/student/ voksen Nærmere produktbeskrivelse finnes på: http://www.177nordland.no/index.php?ac_id=271&ac_parent=280
1.8 Rapportering 1.8.1 Reisestatistikk 1.29 Det skal være enkelt for oppdragsgiver å 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. 1.30 I den grad systemet gir mulighet til det, skal oppdragsgiver kunne hente ut statistikk fordelt på holdeplass, og sone. Dette gjelder både påstigning og avstigning. 1.31 Løsningen skal tilby eget datavarehus. 1.32 Løsningen skal gi oppdragsgiver mulighet til å ta ut egendefinerte rapporter for oppfølging og statistikk. 1.8.2 Regnskap, økonomi 1.33 Løsningen skal innfri de til enhver tid gjeldende krav i lovgivningen til regnskapsog økonomirapporter, herunder kontrollmuligheter for uavhengig tredjepart typisk revisor. Løsningen skal muliggjøre avstemming mot innløserenhet. 1.34 Løsningen må tilfredsstille kravene til daglig kasseoppgjør med transaksjonslogg, summering og spesifikasjon i henhold til bokføringsloven. Det skal også vises avregning, hvordan transaksjonene er oppgjort, og avregning mot oppdragsgiver.
1.9 Teknologisk utvikling 1.35 Tilbudt løsning skal kunne tilpasses/videreutvikles slik at kommunikasjon via NFC støttes. 2. Funksjonalitet og tekniske krav 2.1 Plattform 2.01 Løsningen skal tilbys på is og android. 2.02 Løsningen skal fungere på de nyeste versjonene av operativsystemer, og samtidig være bakoverkompitabel i så stor grad som mulig. 2.2 Skjermrotasjon 2.03 Applikasjoner skal støtte stående format hvor høyden på skjermen er større enn bredden. 2.04 For enheter med mulighet for skjermrotasjon bør løsningen utvikles for å støtte også liggende format. 2.3 Skjerm 2.05 Appen skal ha god visning med bra lesbarhet på skjermstørrelser fra 4 til 6 tommer. 2.06 Applikasjoner må utarbeides slik at høy pikseltetthet blir utnyttet maksimalt. 2.07 Appen skal fungere på skjerm med oppløsning på 480 x 800 piksler (WVGA). 2.08 Appen skal være optimalisert for visning på skjerm med høyere oppløsning enn 720 x 1280 piksler (WXGA).
2.4 Berøringsskjerm 2.09 Appen skal fungere på skjermer med kapasativ teknologi (berøringsskjerm). 2.10 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 2.11 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. 2.12 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 hos oppdragsgiver ikke er i drift. ppetiden skal være på minimum 99,5 %.
3. Betalingsløsning 3.01 Appen skal kunne gjennomføre transaksjoner via innløserbank, eks. Teller, som et nødvendig ledd i transaksjonsrekkefølgen. Leverandør skal være behjelpelig med konfigurasjon mot betalingsintegrator og innløser. 3.02 Bruker skal kunne registrere kortopplysninger for de vanligste bankkort(visa/mastercard). Betalingsformidler lagrer disse opplysningene sikkert ihht. Kortselskapenes retningslinjer. gså mulighet for støtte av utenlandske betalingskort skal drøftes. 3.03 Løsningen skal støtte betaling via mobilregning 3.04 Løsningen skal støtte betaling via reisekonto 4. Øvrig funksjonalitet Mobil arkitektur Løsningen bør skille presentasjon, datamodell og forretningslogikk. Tilbyder bes beskrive arkitekturen i løsningen, og hvilke rammeverk og teknologier, man ser for seg å benytte. Prosjektgjennomføring Tilbyder bes beskrive hvilke(t) verktøy som benyttes til støtte i prosjektgjennomføring, som oppdragsgiver skal forholde seg til. Eksempel på dette kan være «Atlassian Jira versjon x med tilleggsmodulene Y og Z». Tilbyder 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. Tilbyder skal ha et separat testmiljø som er tilgjengelig for oppdragsgiver. Servicedesk Tilbyder skal tilby andrelinje service for oppdragsgivers egne ansatte som er involvert i løsningen. Katastrofeplaner
Tilbyder skal ha beredskap og katastrofeplaner med alternativ driftsløsning som sikrer kontinuerlig drift dersom tilbyders driftsmiljø helt eller delvis settes ut av produksjon, eller på annen måte gjøres utilgjengelig. 5. psjoner 5.1 psjon_1 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 oppdragsgiver 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å oppdragsgiver kunne importere i Excel eller annet format. Alternativt kan løsningen integreres direkte med oppdragsgivers system for håndtering av skoleskyss. Skolekortet skal tilfredsstille de krav som stilles til billett for øvrig. 5.2 psjon_2 perativsystem Vi ønsker en opsjon på å kunne utvide appen til å være tilgjengelig på windows operativsystemet for mobil dersom oppdragsgiver finner det hensiktsmessig. 5.3 psjon_3 Utvidelse Det skal gis opsjon på muligheten til å utvide applikasjon til å gjelde flere byer og/eller større områder i Nordland fylke ved et senere tidspunkt.