Vedlegg 2 SSA-U, bilag 1 Kundens kravspesifikasjon VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 1 av 13
Innholdsfortegnelse 1. Avtalens omfang (Avtalens punkt 1.1)... 3 2. Definisjoner:... 4 3. Kundens krav til leveransen:... 5 3.1 Overordnede krav:... 5 3.2 Krav til krisesenter-modulen... 8 3.3 Krav til web-applikasjonen (til bruk på PC)... 11 3.4 Krav til mobilapplikasjonen... 12 3.5 Opsjoner... 13 Følgende kravspesifikasjon er ikke å betrakte som en fullverdig teknisk kravspesifikasjonen, men heller å betrakte som en funksjonsoversikt. Leverandør skal fylle ut bilag 2 som et svar på bilag 1. VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 2 av 13
1. Avtalens omfang (Avtalens punkt 1.1) Kundens formål med anskaffelsen: Akershus fylkeskommunes politikere vedtok den 16. juni 2014 at det skal utvikles og installeres et system som gir elever og ansatte ved Akershus fylkeskommunes skoler en mulighet for å varsle om alvorlige hendelser. Systemet skal også kunne bidra til at krisen håndteres på beste mulige måte. Varslingen skal gjøres fra eget datautstyr (smarttelefon eller PC), mens krisehåndteringen skjer via en nettleser (tynnklient og stor skjerm). Dette forutsetter at utstyret er koblet til Akershus fylkeskommunes trådløse nettverk. Akershus fylkeskommunes (AFK) har nylig installert et helt nytt trådløst nett fra Aruba. Nettet støtter IEE802.11n. I tillegg er det innført et nytt bredbåndsnett, med god kapasitet til hver enkelt skole (400 Mbps). Ansattes og elevers PC-er er normalt oppkoblet i nettet. Erfaring har vist at mange av smarttelefonene også kobles til, noe AFK har åpnet opp for i sitt nett. Varsling (=utløsing av alarm) skal skje ved at en eller flere trykker på en alarmknapp på smarttelefonen eller i nettleserens verktøylinje. Når alarm utløses, så skal det gå ut talemeldinger til et antall forhåndsdefinerte telefonapparater eller høyttalere. Dette vil typisk være til skolens kriseteam. Selve talevarslingen er funksjonalitet som er knyttet til AFKs telefonisystem, og som vil bli levert av AFK sin nåværende telefonileverandør. Når alarmen utløses, samles skolens kriseteam på avtalt sted (f.eks. rektors kontor). Samtidig startes det opp en eller flere videostrømmer til et sentralt krisesenter. Kriseteamet skrur på tynnklient, logger seg på og kommer rett inn i krisesenteret (via en moderne nettleser). Denne gir umiddelbart oversikt over situasjonen i form av små videobilder (inkl. lyd) fra den eller de som har utløst alarm. Fra krisesenteret skal skolens kriseteam videre kunne få opp kart over skolen som viser hvor alarmen er utløst. Dette krever integrasjon med fylkeskommunens trådløse nettverk. Videre skal skolens kriseteam fra krisesenteret kunne varsle nødetater, elever og ansatte, via tale-, lyn- og tekstmeldinger. Det fysiske utstyret som kreves for at den løsningen leverandøren tilbyr skal fungere, omfattes ikke av denne avtalen. AFK kjøper det eventuelle utstyret over eksisterende rammeavtale på IKT-utstyr. Følgende kravspesifikasjon er ikke å betrakte som en fullverdig teknisk kravspesifikasjonen, men heller å betrakte som en funksjonsoversikt. Leverandør skal fylle ut bilag 2 som et svar på bilag 1. VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 3 av 13
En grov skisse av de forskjellige komponentene i den tenkte løsningen er som følger: 2. Definisjoner: Gi alarm: Utløse en alarm Alarmgiver: Personen som utløser alarmen Fysisk alarmgiver: En fysisk bryter alarmgiver kan trykke på for å utløse alarm (ref. bryter for å utløse brannalarm) Krisesenter: Den tekniske løsningen som skal gi skolens kriseteam en oversikt over hendelsen, og hvor tiltak skal kunne utføres. Eksempel på tiltak: Sende ut skreddersydde lynmeldinger og sms, og varsle nødetater. Tekstmelding: Mobilnettets tekstmelingssystem (eng: Short Message Service - sms) Lynmelding: Tekstmeldingssystem på Internett, også kalt direktemelding (eng: Instant messaging (IM) eller Chat ) VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 4 av 13
3. Kundens krav til leveransen: 3.1 Overordnede krav: Krav nr Beskrivelse 3.1.1 Standarder og teknologi AFK ønsker primært at løsningen baseres på de åpne Internett-standardene og fri programvare. Den nye standarden for video på web, WebRTC, må gjerne benyttes (AFK er kjent med begrensingen i antall videostrømmer, og ser dette ikke som noen vesentlig ulempe). Leverandøren skal i bilag 2 spesifisere de standardene og fri programvare-komponentene som leverandøren planlegger at skal inngå i løsningen. Bruk av fri programvare reguleres av avtalens punkt 10.3. 3.1.2 Tilgang til kildekoden Det er ønskelig at løsningen gjøres tilgjengelig under en fri programvarelisens, eksempelvis GPL. Dersom leverandør tilbyr en løsning basert på standardprogramvare (proprietær programvare), skal leverandøren, ved signering av avtalen, inngå en ESCROW-avtale (deponeringsavtale for kildekoden) med Kunden. Eventuelle kostnader knyttet til en slik avtale skal dekkes av leverandøren. Dersom organisasjoner (ikke enkeltpersoner) ønsker å kontrollere den tilbudte løsningens funksjonalitet i henhold til personopplysningsloven, skal Kunden til en hver tid få innsyn i kildekoden. Dette gjelder både om leverandør tilbyr standard og/eller fri programvare. 3.1.3 Krav til utviklingsprosessen Da dette ikke er en endelig kravspesifikasjon, betyr det at det vil dukke opp spørsmål underveis. Det vil være mange valg AFK må ta stilling til. Valgene, fortrinnsvis med flere alternativer, må presenteres AFK løpende gjennom hele prosjektperioden (Iterativ utviklingsprosess). Tilbyder må legge til rette for tilstrekkelig tid til både fysiske møter og video- /telefonmøter med AFK. Som et utgangspunkt ser AFK for seg inntil 10 fysiske møter og 10 møter pr video-/telefon, fra avtale er undertegnet til idriftsettelse. Snittvarighet per møte: 4 timer. Øvrige bestemmelser for utviklingsprosessen fremkommer av bilag 4 og 5. 3.1.4 Krav til teknologisk plattform (maskinvare og operativsystem) AFK har en virtuell plattform basert på VMware som ønskes benyttet. Vi ber tilbyder tydelig angi systemkrav til maskinvare og angi hvilket operativsystem som anbefales. Dersom tilbyder anbefaler fysiske servere, bes tilbyder beskrive årsaken til det, samt antall og systemkrav. Leverandør skal IKKE beskrive kostnader ved besvarelse av dette kravet, men utførlig beskrive minimumskrav samt anbefalte krav til program- og maskinvare for å drifte tilbudt løsning. Oppdragsgiver gjør selv en beregning av egne driftskostnader på bakgrunn av egne innkjøpsavtaler på maskinvare. Driftskostnader vil tillegges tilbudt totalpris ved vurderingen av tildelingskriteriet pris. VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 5 av 13
3.1.5 Krav til drift Løsningen vil normalt ikke bli benyttet, følgelig vil det være viktig å innarbeide mekanismer som sjekker at løsningen er i operativ drift. I utgangspunktet ser AFK for seg å drifte dette selv. Det skal derfor utarbeides, som en del av prosjektet, en komplett driftshåndbok. Denne skal som et minimum inneholde: Overvåking: Beskrive de overvåkingsverktøy og varslingsmekanismer som etableres for å overvåke driftssituasjonen. Daglig drift: Sjekk av tjenester (verifikasjon av at tjenestene kjører) Sjekk av status database Sjekk av lagring Sjekk av minne/ytelse Det må fremgå hva som må sjekkes manuelt og hva som automatisk overvåkes. Ved automatisk overvåking, skal det beskrivelse hva som overvåkes, hvordan det overvåkes, og hvordan hendelser varsles. Ukentlig/månedlig: Sikkerhetskopiering (Backup), inkl beskrivelse av backup-rutinen. Feilsituasjoner: Rutiner for håndtering av feilsituasjoner; stopp av tjenester, virusangrep, maskinvarefeil, minnelekkasjer, brann etc. Rutine for restore av backup Som opsjon ønskes tilbud på drift (se krav 3.5.1). 3.1.6 Behandling av personopplysninger, avtalens punkt 9.2 Da løsningen er tenkt driftet hos Kunden skal også personopplysninger lagres på Kundens maskiner. Forhold som gjelder personopplysninger er Kundens ansvar. AFK sin IT-avdeling håndterer personopplysninger etter gjeldene regelverk og forskrift. Om Leverandør tilbyr en løsning som ikke innebærer intern drift av systemet hos Kunden, skal Leverandør i sitt bilag 2 utførlig beskrive hvordan personopplysninger skal behandles. 3.1.7 Krav til support og vedlikehold Dette er en løsning som normalt ikke vil bli benyttet, slik at det kan forventes lite behov for support. Vi er også opptatt av at løsningen ikke endres vesentlig, verken med ny funksjonalitet eller endringer i brukergrensesnittet. Dette for at brukerne skal kjenne igjen løsningen de få gangene den tas i bruk (forhåpentligvis kun gjennom en årlig øvelse). Imidlertid vil det være behov for noe programvarevedlikehold, type oppdateringer og oppgraderinger av de anvendte programvarekomponentene som inngår i løsningen. Det skal derfor gis tilbud på support og vedlikehold i form av ferdig forslag til utfylt Statens Standardavtale for vedlikehold (SSA-V lille). Det er kun AFKs IT-personell som skal kunne kontakte tilbyders supportsenter. VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 6 av 13
3.1.8 Krav til dokumentasjon Det skal leveres dokumentasjon i henhold til avtalen, punkt 2.3.5. Videre gir Kunden følgende føringer for utarbeidelse av dokumentasjon: 1. Systemdokumentasjon: Denne skal beskrive samtlige komponenter som inngår i systemet, samt det overordnede designet. Eventuell databasemodell eller lignende skal beskrives, med skisser. 2. Brukerdokumentasjon: Det skal leveres brukerdokumentasjon til krisesenteret. Denne skal være svært enkel og lettfattelig. Vi ser for oss et enkelt A3-ark med skjermbilder og forklaringer. 3. Driftsdokumentasjon: Se krav 3.1.5 vedr. drift. 3.1.9 Krav til opplæring Som en del av prosjektet skal det leveres opplæring. Denne skal skje i form av en gjennomgang av levert dokumentasjon, ref. pkt 3.1.8. Følgende skal det gis opplæring til: System- og driftsdokumentasjon: AFKs sentrale driftspersonell (maks 8 timer) Brukerdokumentasjon: Prosjektgruppen (4 personer, maks 2 timer) AFK er selv ansvarlig for opplæring av personell ved den enkelte skole. VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 7 av 13
3.2 Krav til krisesenter-modulen Krav nr Beskrivelse 3.2.1 Funksjonsbeskrivelse Krisesenter-modulen er selve kjernen i systemet. Det skal være en web-løsning, med integrasjon mot AFKs trådløse løsning (Aruba) og telefonisystemet (TS200). Ved utløsning av alarm fra smarttelefon eller PC, skal det opprettes sanntids mediastrøm mellom den/de som har gitt alarm og til en sentral server (krisesenteret). Mediastrømmen skal bestå av video (inkl. lyd) fra den klienten som har utløst alarm til den sentrale krisesenterløsningen. Det skal i utgangspunktet ikke gå video- eller talestrøm motsatt vei. I tillegg skal det være en chat-mulighet mellom den klienten som har utløst alarm og krisesenter-løsningen. Hver enkelt brukers videovindu i krisesenter-løsningen skal på en webside presenteres gjennom et videovindu i størrelsesordenen 5x5 cm (se vedlagte skisse), med et noe mindre chat-vindu rett under. Samtidig skal det sendes ut varsling via sms og høyttalere til et på forhånd bestemte antall numre/enheter, med melding om at Alarm er utløst, vennligst møt opp på avtalt sted. For talevarslingen skal denne meldingen gjentas et på forhånd konfigurerbart antall ganger. 3.2.2 Krav til antall video-, chat- og talestrømmer Krisesenteret skal kunne etablere minimum 7 samtidige videostrømmer (inklusive lyd). Tilbyder er fri til å velge teknologi for å realisere løsningen, men vi gjør oppmerksom på at dette trolig lar seg realisere ved å benytte den nye web-standarden for sanntidskommunikasjon på web, WebRTC. AFK er kjent med at dette er en peer-to-peer kommunikasjonsform, noe som gir visse begrensninger med hensyn til antall samtidige videostrømmer. Pr i dag ligger denne på 7-8. Dette ansees ikke å være et problem, fordi 7-8 videostrømmer bør kunne gi mer enn nok informasjon for at skolens kriseteam skal kunne danne seg et bilde av situasjonen. I tillegg skal den etablere tale- og lynmeldingskanaler til samtlige som utløser alarm. Hvor mange dette kan dreie seg om er vanskelig å si, men for alle praktiske formål vil det neppe overgå 30. Talekanalene skal gå inn i en telefonkonferanse, slik at skolens kriseledelse hører alle alarmgiverne. Alarmgiverne skal ikke høre noe (se krav knyttet til klientene). Alarmgivere som utløser alarm, og hvor det maksimale antall videostrømmer er aktivisert, så skal systemet detektere dette, og kun etablere lynmeldingstjenesten (ev. også overføre lyd) Krisesenteret skal imidlertid kunne stenge en videostrøm, for å opprette en videostrøm mot en annen alarmgiver. Dette skal kunne gjøres med enkle klikk på knapp eller rett på det området som viser/skulle vist videobildet. VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 8 av 13
3.2.3 Krav til angivelse av posisjon på kart - integrasjon mot Aruba trådløs-løsning AFK installerte sommeren 2013 nytt trådløst nettverk fra Aruba Networks. I denne løsningen finnes muligheten for å hente ut posisjoneringsdata for der de trådløse enhetene befinner seg. Dette skal plottes på byggetegninger over skolen, slik at kriseteamet lett ser hvor hendelsen har oppstått. Tilbyder skal stå for denne integrasjonen. Dersom tilbyder ikke innehar denne kompetansen selv, skal tilbyder inngå et samarbeid med en underleverandør. Leverandøren skal utførlig beskrive eventuelle underleverandører som skal utføre denne delen av oppdraget. AFK er ansvarlig for å fremskaffe gjeldende byggetegninger. 3.2.4 Krav til integrasjon mot telefonisystemet Telefonisystemet til AFK er levert av selskapet Simcom AS i Oslo. Systemet er basert på åpne Internett-standarder (SIP, RTP m.fl.) og markedsledende open source-komponenter (Asterisk, Kamailio, PostgreeSQL m.m.). Integrasjonen skal sørge for at: 1. Når alarm utløses, så skal det fra telefonisystemet gå ut en standard talemelding til kriseteamets telefonapparater (inkl. mobiltelefonene) og ev. ekstra høyttalere. Meldingen leses inn i telefonisystemet. Forslag til melding: Alarm er utløst. Kriseteamet møter på avtalt sted. Melding gjentas x antall ganger (angis i telefonsystemet). 2. Dersom en av medlemmene i kriseteamet sitter opptatt i telefonen, skal telefonisystemet bryte inn i samtalen og sende en talemelding til medlemmet i kriseteamet og en annen til den andre parten. 3. Telefonsystemet, ev. AFKs sms-løsning, skal kunne sende tekstmeldinger til grupper av brukere. Den enkleste formen for integrasjon på dette, er at denne tjenesten betjenes fra telefonisystemet i en egen fane i nettleseren. Tilbyder bes beskrive andre måter dette kan gjøres på. 4. Utsendelse av talemeldinger (talevarsling). Telefonsystemet skal kunne sende skreddersydde eller forhåndsinnspilte meldinger til en gruppe klienter (telefonen og høyttalere). Den enkleste formen for integrasjon på dette, er at denne tjenesten betjenes fra telefonisystemet i en egen fane i nettleseren. Tilbyder bes beskrive måter dette kan gjøres på. Det er lagt opp til at SimCom bidrar i prosjektet ved etableringen av denne integrasjonen. Kostnader knyttet til SimComs arbeid, dekkes utenom dette anbudet. 3.2.5 Krav til styring/kontroll av lyd og bilde Fra krisesenteret skal man kunne slå av og på både video- og lydstrømmer. Lynmeldingskanalen skal det ikke være mulig å skru av (dvs. at lynmeldingskanalen alltid skal være åpen mot vedkommende som utløste alarmen). 3.2.6 Krav til utsendelse av meldinger til alle eller en avgrenset gruppe Fra krisesenteret skal man som minimum kunne sende både tekstmeldinger og/eller lynmeldinger til: Alle alarmgiverne (de som har utløst alarm) De som befinner seg i samme område som alarmgiverne (men som ikke har utløst alarm) Øvrige brukere (=de som befinner seg litt unna der hendelsen har oppstått) VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 9 av 13
3.2.7 Krav til video- og lydkvalitet Video- og lydkvalitet vil for alle praktiske formål begrenses av klientene. Som et minimum skal ikke video- og talekvaliteten være dårligere enn hva de beste klientene i dag kan klare (Samsung Galaxy S5, Sony Experia Z3 og iphone 6). 3.2.8 Krav til grafisk design (brukergrensesnittet) Det skal utvikles et funksjonelt og brukervennlig brukergrensesnitt, i utgangspunktet basert på skisser gitt i vedleggene, men AFK er åpen for forslag for andre løsninger. Det er viktig å tenke på situasjonen for når dette systemet er tenkt benyttet. Utviklingen av selve brukergrensesnittet skal være basert på en tett dialog med AFK. Leverandør skal fremlegge skisser, og når AFK er fornøyd med utkastet, skal dette realiseres elektronisk. Når brukergrensesnittet er realisert elektronisk, kan kun mindre justeringer skje (finjustering av plasseringen av objekter, farger, skrifts-/objektstørrelser m.m.) 3.2.9 Krav til fysiske alarmgivere Krisesenteret skal kunne ta i mot alarmer fra fysiske alarmgivere. Dette kan f.eks. være SIPbaserte giver. Eksempelvis: http://www.cyberdata.net/products/voip/digitalanalog/callbutton/index.html eller tilsvarende. Tilbyder bes beskrive hvilke typer fysiske alarmgiver som anbefales. Tilbudet skal ikke inkludere disse (anskaffelse av slikt utstyr vil skje over en egen rammeavtale for telefoniutstyr). VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 10 av 13
3.3 Krav til web-applikasjonen (til bruk på PC) Krav nr Beskrivelse 3.3.1 Funksjonsbeskrivelse Når brukeren klikker på ikonet (=alarmknappen), skal det komme opp en ny knapp eksakt der muspekeren befinner seg, med følgende tekst: Sikkert at du vil dette? Teksten skal presenteres brukeren på en rekke språk. Et klikk er det eneste som skal til for å bekrefte. Når brukeren klikker en gang til, skal det utløse alarm, og en ny fane i nettleseren åpnes. Hvordan den grafiske utformingen av denne siden skal se ut, avklares i designfasen av prosjektet. En idé kan være at den skal etterligne en kjent side, f.eks. en vilkårlig side i skolens e-læringsplattform. Forskjellige sider skal presenteres de forskjellige alarmgiverne (random). Hensikten er og ikke avsløre ovenfor en gjerningsmann at alarm er utløst. Nederst på siden skal selve lynmeldingsfeltet være. Det skal være forholdvis lite, og ikke lett å oppdage ved første øyekast. Størrelse på vinduet bestemmes i prosjektet. I det alarmen utløses, skal det umiddelbart gå ut tale- og sms-meldinger til skolens kriseteam, samt at det opprettes en videostrøm og lynmeldingskanal mellom klienten og krisesenteret, som overfør lyd og video fra klienten, men ikke motsatt vei. Derimot skal lynmeldinger både kunne sendes og mottas. I tillegg skal det på websiden stå, f.eks. rett under lynmeldingsfeltet, en tekst som gir instruksjon til alarmgiveren om at skolens kriseteam hører vedkommende, men at alarmgiveren ikke hører dem. Forslag til tekst: Vi hører deg. Kan du snakke? Vil du høre oss, klikk her En utfordring blir å hindre at klientens innebygde lampe (lysdiode) starter å lyse når alarm utløses (dvs. når kameraet aktiviseres). Vi ber tilbyder beskrive hvorvidt dette er mulig eller ikke. Dersom det er mulig, så skal kostnaden for å implementere dette være inkludert i tilbudet. 3.3.2 Krav til OS og nettleser Som nevnt under Krav til krisesenteret, åpner vi opp for å benytte den nye webstandarden for sanntids-/videokommunikasjon (WebRTC) for å overføre video og tale. Dette er i dag en gjennomprøvd standard, som allerede har fått stor utredelse. Per i dag støttes den nye webstandarden webrtc av tre anerkjente nettlesere; Firefox, Chrome og Opera. Vi legger derfor til grunn at løsningen benytter seg av disse tre nettleserne. Det er grunn til å tro at Microsoft og Apple med tiden også vil bygge inn webrtc-støtte i en fremtidig versjon av sin nettleser. (Microsoft er en betydelig bidragsyter til Object RTC API-et for WebRTC (en forbedring til dagens WebRTC 1.0) og det er ventet at Microsoft vil bygge inn støtte for den kommende WebRTC-versjonen). Løsningen skal ikke være bundet til et bestemt OS. 3.3.3 Krav til plugin til nettleser Det skal utvikles en plugin til de aktuelle nettleserne. Pluginen skal gjøres fritt tilgjengelig fra de respektive nettlesernes markedsplasser. Kostandene knyttet til etablering og deltagelse på disse markedsplassene skal være inkludert i prisen. Etter installasjon skal den synliggjøres som et lite, diskré ikon på nettleserens verktøylinje. VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 11 av 13
3.4 Krav til mobilapplikasjonen Krav nr Beskrivelse 3.4.1 Funksjonsbeskrivelse Mobilapplikasjonen skal være svært enkel. Mobilapplikasjonen har tre hovedfunksjoner: Gi brukeren mulighet å varsle (gi alarm), for deretter å overføre en kontinuerlig videostrøm (inklusive lyd), samt etablere en lynmeldingskanal til krisesenteret. Den skal kun inneholde to skjermbilder: Det første skjermbildet som kommer opp idet du starter app-en inneholder en alarmknapp. Når alarm er utløst, skal neste vindu umiddelbart komme opp. Som for web-siden, kan man tenke seg at siden ser ut som noe helt annet, og at feltet for lynmeldinger kun vises i nedre del av skjermen. Som på web-siden, skal det under feltet stå en tekst, f.eks. Vi hører deg. Kan du snakke? Vil du høre oss, klikk her. Videosamtalen skal ikke presenteres (vises) i app-en. Videostrømmen skal kun gå en vei, fra app-en og til krisesenteret. 3.4.2 Krav til støttede OS-er (telefoner) Applikasjonen skal støtte smarttelefoner med operativsystemet ios og Android. Som opsjon ønskes tilbud på støtte for Windows Phone, se krav 3.5.2. 3.4.3 Krav til grafisk utforming De to vinduene skal utformes på en slik måte at de ikke gir assosiasjoner ovenfor en eventuell gjerningsmann at dette er en alarm-app. Som en del av prosjektet, skal det tas frem flere forslag til grafisk utforming. Tilbyder bes ta høyde for at det som minimum skal legges fram tre forslag, og at mindre justeringer på det valgte forslaget vil skje. 3.4.4 Krav til styring av lyd og kamera Når alarmen utløses, skal smarttelefonens høyttalervolum skrus helt ned, samtidig som kameraet aktiviseres. Eventuelle indikatorlamper som viser at kameraet er aktivisert skal ikke aktiviseres. Oppdragsgiver er kjent med at dette muligens ikke så lett lar seg løse, men vi har hørt om løsninger hvor dette er mulig. Vi ber tilbyder utdype dette nærmere, og ev. beskrive hvordan lampen hindres i å bli skrudd på. 3.4.5 Krav til publisering på Apples App Store og Google Play Tilbyder skal gjøre mobilapplikasjonen tilgjengelig på hhv Apples App Store og Google Play. Kostnadene knyttet til etablering og deltagelse på disse markedsplassene skal være inkludert i prisen. I informasjonen om app-en skal bruksvilkårene tydelig fremgå. Disse vil bli utarbeidet som en del av prosjektet. 3.4.6 Krav til å kjøre i bakgrunnen ( push ) Applikasjonen skal kjøre i bakgrunnen, for å kunne motta tekst-notifikasjoner ( push notifications). VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 12 av 13
3.4.7 Krav til strømforbruk Strømforbruket skal ikke overgå strømforbruket som sammenlignbare applikasjoner har ( pushnotifikasjoner, a la Facebooks Messenger). Et for høyt strømforbruk kan medføre at brukerne avinstallerer applikasjonen. 3.5 Opsjoner Krav nr Beskrivelse 3.5.1 Drift Som opsjon er det ønskelig med et tilbud på en fulldriftet løsning («hosted solution»). Det er tenkt at løsningen skal installeres på AFKs egne maskiner i AFKs driftssenter, men at tilbyder er ansvarlig for driftsoppgavene (som angitt i krav 3.1.7). Pris på opsjon for drift skal angis i tilbudsskjema (bilag 7) og skal inkludere alle kostnader knyttet til de driftsoppgavene som er angitt i krav 3.1.7, om ikke annet er angitt i bilag 2. 3.5.2 Støtte for Windows Phone Som opsjon ønskes det at mobilapplikasjonen også utvikles for Windows Phone. Kostnader knyttet til etablering og deltakelse på Windows Phone sin markedsplass skal spesifiseres i tilbudsskjemaet (under opsjoner). VEDLEGG 2, SSA-U BILAG 1 KUNDENS KRAVSPESIFIKASJON Side 13 av 13