JHS 129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen

JHS 129 Julkisten verkkopalvelujen suunnittelu ja kehittäminen Versio: palautekierrosversio Julkaistu: Voimassaoloaika: toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen rakenne... 2 2 Soveltamisala... 2 3 Viittaukset... 3 4 Termit ja lyhenteet... 4 5 Verkkopalvelun yleiset periaatteet ja reunaehdot... 8 5.1 Verkkopalvelun tavoitteiden ja hyötyjen määrittely... 10 5.2 Verkkopalvelut osana kokonaisarkkitehtuuria ja palveluiden viitearkkitehtuureja... 11 5.3 Palvelun johtaminen ja hallinta... 12 6 Esiselvitys verkkopalvelun kehittämisestä... 14 6.1 Konseptin määrittely... 15 7 Verkkopalvelun vaatimusten ja toiminnallisuuksien määrittely... 17 7.1 Toiminnallisten vaatimusten määrittely... 18 7.2 Verkkopalvelun käyttäjälähtöisyyden vaatimukset... 18 7.3 Verkkopalvelun tietomalli... 23 7.4 Sisällön suunnittelu ja sisällöntuotannon organisointi... 23 7.5 Verkkopalvelun rakenteen suunnittelu... 24 7.6 Palvelun käyttöliittymän suunnittelu... 24 8 Verkkopalvelun hankinta ja kilpailutus... 28 9 Verkkopalvelun toteutus, testaus ja käyttöönotto... 29 9.1 Verkkopalvelun pilotointi... 30 9.2 Verkkopalvelun testaus... 30 9.3 Verkkopalvelun käyttöönotto ja tuotantokelpoisuuden varmistaminen... 30 10 Verkkopalvelun ylläpito... 30 11 Tietoturvallisuus... 31 12 Opastavat tiedot... 32 13 Liitteet... 32 1/32

1 Johdanto Tämän suosituksen tarkoituksena on opastaa julkisen hallinnon organisaatioita verkkopalveluiden (verkkosivustojen ja asiointipalveluiden) suunnittelussa, hankinnassa ja toteutuksessa. Tässä suosituksessa annetut suositukset ja ohjeet tulee huomioida palvelun kehittämisprosessin eri vaiheissa palvelun suunnittelusta palvelun hankinnan ja toteutuksen kautta sen käyttöönottoon ja ylläpitoon ja jatkokehittämiseen. 1.1 Suosituksen rakenne Suosituksen aluksi kuvataan verkkopalvelun perustamisen yleiset edellytykset ja reunaehdot. Lisäksi annetaan suosituksia verkkopalvelun kehittämisestä ja hallinnasta. Suosituksen loppuosa on koostettu palvelun elinkaarimallin mukaisesti. Elinkaari koostuu eri vaiheista ja niissä suoritettavista tehtävistä ja toimenpiteistä. Tässä suosituksessa kuvattuja vaiheita ovat esiselvitys verkkopalvelun kehittämisestä, vaatimusmäärittely, hankinta ja kilpailutus, toteutus, testaus ja käyttöönotto sekä ylläpito (kts. kuva 1). Olennainen osa elinkaariajattelua on myös jatkuva ja hallittu kehittäminen, jota kuvaa tässä suosituksessa mm. luku 5.3 Palvelun johtaminen ja hallinta. Liitteessä 1 on käsitelty muuttuvan toimintaympäristön huomioimista ja liitteeseen 2 on kerätty verkkopalvelun kehittämiseen ja ylläpitoon liittyvää lainsäädäntöä. Kuva 1 Palvelun kehittämisen elinkaari ja sen hallinta 2 Soveltamisala Tavallisimmin verkkopalvelu on avoin www-sivusto, jota käytetään selaimella ja jossa on tietosisältöä tai sähköisiä asiointipalveluita. Tämä suositus soveltuu myös verkkopalveluihin, joita voidaan käyttää erilaisilla 2/32

päätelaitteilla. Suositus soveltuu pääosin myös suljettuihin verkkopalveluihin, kuten intraneteihin ja ekstraneteihin, sekä sellaisin sovelluksiin tai mobiilisovelluksiin, joita ei lueta selaimella, jos sisältö ja käyttöliittymä muistuttavat paljolti tyypillistä www-sivustoa. Esimerkiksi mobiilisovelluksella toimiva verkkolehti tai asiointipalvelu ovat tämäntyyppisiä palveluita. Verkkopalvelulla ei tarkoiteta tässä yhteydessä esimerkiksi palvelimen verkkoon tarjoamia palveluita (network services) tai sulautettuja järjestelmiä (en. embedded, sulautettu, katso: http://www.tsk.fi/tsk/termitalkoot/ ). Tätä suositusta voi hyödyntää myös verkkopalveluihin, joiden käyttötarkoitus tai käyttäjäryhmät ovat hyvin rajattuja, kuten joidenkin ammatti- tai erityisryhmien verkkopalvelut, vaikka suositus ei ole erityisesti suunniteltu sitä varten. Suositus ei kaikilta osin sovellu suhteellisen monimutkaisille internetsovelluksille, kuten vaativammille karttasovelluksille, sähköposti- tai puhelinsovelluksille, ammattikäyttöön tarkoitetuille sovelluksille ja järjestelmille, peleille tai pelillistetyille palveluille. Suositukset eivät myöskään kaikilta osin sovellu ääni- tai liikeohjattuihin käyttöliittymiin. Tämä suositus korvaa vuonna 2005 julkaistun JHS 129 Julkishallinnon verkkopalvelun suunnittelun ja toteuttamisen periaatteet -suosituksen. Suosituksen kohderyhmiä ovat: toiminnan ja prosessien - omistajat - kehittäjät palvelun tai palveluiden - toteuttamisesta päättävät tai palveluita hankkivat henkilöt - suunnittelusta ja kehittämisestä vastaavat henkilöt - sisällöntuottajat - tekniset toteuttajat - toimittajat - ulkoasun suunnittelijat tietojärjestelmien - kehittäjät - kehityshankkeiden vetäjät ja asiantuntijat. 3 Viittaukset Suositustekstissä olevat viittaukset lakeihin, normeihin ja säädöksiin: SÄHKE2-määräys http://www.arkisto.fi/fi/palvelut/julkisen-hallinnon-saehkoeiset-palvelut/saehke-maeaeraeykset EU:n direktiiviehdotus julkisen sektorin elinten verkkosivustojen saavutettavuudesta (COM(2012) 721) http://eur-lex.europa.eu/lexuriserv/lexuriserv.do?uri=com:2012:0721:fin:fi:html Laki julkisista hankinnoista (348/2007) http://www.finlex.fi/fi/laki/ajantasa/2007/20070348 Muut verkkopalvelujen kehittämiseen, hallintaan ja ylläpitoon liittyvät lait, kts. liite 2 Lainsäädäntöluettelo. Suositukseen liittyviä muita suosituksia ovat: 3/32

JHS 143 Asiakirjojen kuvailun ja hallinnan metatiedot JHS 152 Prosessien kuvaaminen JHS 166 Julkisen hallinnon IT-hankintojen yleiset sopimusehdot (JIT 2007) JHS 167 Neuvottelumenettelyjen käyttö ICT-hankinnoissa JHS 169 Avoimen lähdekoodin ohjelmien käyttö julkisessa hallinnossa JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen JHS 172 ICT-palvelujen kehittäminen: Esiselvitys JHS 173 ICT-palvelujen kehittäminen: Vaatimusmäärittely JHS 174 ICT-palvelujen palvelutasoluokitus JHS 176 Sähköisten asiakirjallisten tietojen käsittely, hallinta ja säilyttäminen JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen JHS 183 Julkisen hallinnon palvelujen tietomalli ja ryhmittely verkkopalveluissa. Suositukseen liittyviä VAHTI-ohjeita (www.vm.fi/vahti) ovat: VAHTI 2/2013 Sovelluskehitysohje VAHTI 2/2012 ICT-varautumisen vaatimukset VAHTI 4/2010 Sosiaalisen median tietoturvaohje VAHTI 12/2006 Tunnistaminen julkishallinnon verkkopalveluissa -ohje VAHTI 9/2006 Käyttövaltuushallinnon periaatteet ja hyvät käytännöt VAHTI 1/2003 Valtion tietohallinnon Internet-tietoturvallisuusohje Suositustekstissä olevat viittaukset standardeihin ja teknisiin eritelmiin: WCAG 2.0 eli Web Content Accessibility Guidelines 2.0 http://www.w3.org/tr/wcag/ ISO 9241-11 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=16883 4 Termit ja lyhenteet esiselvitys fi esiselvitys ennen tietojärjestelmän vaatimusmäärittelyä ja tietojärjestelmähankintaa tehtävä selvitys Esiselvityksen osa-alueita ovat mm. toimintaympäristön kartoitus, tavoiteratkaisun tarkentaminen ja tietoturvallisuuden kartoitus. hallintamalli fi hallintamalli malli, joka käsittää roolien ja vastuiden määrittelyn, organisoinnin, johtamisen ja hyödyntämisen prosessit sekä toimintamallin HTML5 fi HTML5 4/32

formaali merkintäkieli, jolla kuvataan tekstin ja verkkosivujen rakennetta ja niihin liittyvää metatietoa HTML5 on uusimman sukupolven versio verkkosivujen tekemiseen käytetystä HTML-kuvauskielestä. Verrattuna aiempiin HTML-versioihin HTML5 tarjoaa yhtenäisen ja eri laiteympäristöissä toimivan toteutusmallin verkkosovelluksille, piirrosgrafiikalle ja monille vuorovaikutuksellisille toiminnoille, kuten elementtien siirtämiselle (vedä ja pudota, drag and drop). kokonaisarkkitehtuuri fi kokonaisarkkitehtuuri; KA toiminnan, prosessien ja palvelujen, tietojen, tietojärjestelmien ja niiden tuottamien palvelujen muodostaman kokonaisuuden rakenne, jolla hallinnoidaan ja kehitetään organisaation toimintaa ja sen rakenteita Kokonaisarkkitehtuuri on malli, jossa tietotekninen varustus kuvataan ja huomioidaan osana liiketoimintaa tai muuta toimintaa. Kokonaisarkkitehtuuri on kokonaisvaltainen lähestymistapa organisaation toiminnan ja sen rakenteiden hallinnoimiseksi ja kehittämiseksi. Kokonaisarkkitehtuurilla tarkoitetaan toiminnan, tietotarpeiden, tietojärjestelmien ja teknologiaratkaisujen mallintamista, kuvaamista ja suunnittelemista yhtenäisen mallin mukaisesti. Kokonaisarkkitehtuuri varmistaa eri osa-alueiden ja erityisesti toiminnan tarpeiden yhdenmukaisen huomioimisen kaikessa toiminnan ja ICT-ratkaisujen kehittämisessä. Käytännössä kokonaisarkkitehtuuri koostuu kokonaisarkkitehtuurimenetelmästä, kuvauspohjista ja näiden avulla toteutetuista nyky- tai tavoitetilan arkkitehtuurilinjauksista sekä kokonaisarkkitehtuurin hallintamallista ja arkkitehtuurityön organisoinnista. konsepti fi konsepti Verkkopalvelun konseptilla tarkoitetaan yleensä verkkopalvelun palveluideaa. Joskus konseptilla tarkoitetaan myös palvelun prototyyppiä tai muuta alustavaa suunnitelmaa. Konseptisuunnitelmalla tarkoitetaan näiden dokumentoitua kuvausta. Konseptin käsite jaetaan joskus ylätason konseptiksi ja käyttöliittymäkonseptiksi. Ylätason konseptisuunnitelma kuvaa palvelun ja viestinnän keskeiset tavoitteet, käyttäjäryhmät ja käyttäjien tarpeet. Käyttöliittymäkonseptissa kuvataan palvelun käyttöliittymän perusrakenne esimerkiksi konkreettisina käyttöliittymämalleina ja tietorakennekuvauksina. Visuaalisen ilmeen konseptisuunnitelmalla tarkoitetaan puolestaan graafisen suunnittelijan tekemää ehdotusta tai luonnosta palvelun ilmeestä tai graafisesta oheistuksesta. Konseptisuunnitelmia käytetään usein tavoitteita kuvaavina dokumentteina myöhempien vaihteitten kilpailutuksessa. käytettävyys fi käytettävyys en usability palvelun käytön helppous, miellyttävyys ja tehokkuus todellisissa käyttötilanteissa ISO 9241 11 -standardi määrittelee käytettävyyden siten, että tarkoin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi. 5/32

käyttäjälähtöinen suunnittelu fi käyttäjälähtöinen suunnittelu en user-centered design JUHTA - Julkisen hallinnon tietohallinnon neuvottelukunta suunnitteluperiaate, jonka lähtökohtana pidetään käyttäjien toiveita ja tarpeita ja jolla pyritään esteettömyyteen laitteiden, palveluiden ja rakennetun ympäristön käytössä Käyttäjänäkökulma pidetään mukana koko suunnitteluprosessin ajan. Menettelyllä pyritään takaamaan tuotteen hyödyllisyys ja helppokäyttöisyys. Kansainvälisen ISO 13407:1999 -standardin mukaan käyttäjäkeskeiseen suunnitteluprosessiin kuuluu tarvittaessa uudelleen toistettavina vaiheina käyttökontekstin ymmärtäminen ja määrittely, käyttäjävaatimusten ja organisaation vaatimusten määrittely, suunnitteluratkaisujen tuottaminen sekä evaluointi. Käyttäjälähtöinen suunnittelu edellyttää entistä enemmän eri alojen yhteistyötä, koska suunnittelun ongelmat ovat monitahoisia. metatiedot fi metatieto en metadata tietoa kuvaileva tieto Metatietojen tulee noudattaa jotain yleisesti hyväksyttyä ja käytettyä mallia, sanastoja, ontologioita yms., jotta ne olisivat käyttökelpoisia. Yleisiä ongelmia metatietojen hyödyntämisessä ovat luonnollisten kielien runsaus ja monimutkaisuus, koneellisen tulkinnan vaikeudet, ongelmat sanastojen käytössä ja kehittämisessä ja se, että ohjelmat tallentavat metatiedot sellaisessa muodossa, ettei niitä ole mahdollista hyödyntää ilman kyseistä ohjelmaa. mobiililaite fi mobiililaite en mobile device mukana kuljetettava laite, johon voidaan asentaa sovelluksia ja/tai jossa on käytössä internet-selain Mobiililaitteiksi lukeutuvat muun muassa erilaiset älypuhelimet, taulutietokoneet, näiden välille asettuvat taskukokoiset älylaitteet sekä e-kirjojen lukulaitteet, joille on tyypillistä pienempi näyttökoko ja kosketusnäyttö. saavutettavuus fi saavutettavuus; esteettömyys en accessibility ominaisuus, joka ilmentää sitä, kuinka helposti henkilö voi ottaa järjestelmän, laitteen, ohjelman tai palvelun käyttöönsä tiedonhallinta fi tiedonhallinta en information management; info management 6/32

tiedon keruu, organisointi ja tallentaminen siten, että se on helposti löydettävissä ja käytettävissä tietomalli fi tietomalli en data model malli, joka kuvaa tietoa ja tietojen välisiä suhteita toiminnallinen vaatimus fi toiminnallinen vaatimus vaatimus, joka määrittelee kehitettävän tai hankittavan järjestelmän käyttäytymistä tai toiminnallisuutta Toiminnalliset vaatimukset määrittelevät, mitä palveluja ohjelmiston on tarjottava, miten ohjelmisto reagoi syötteisiin ja miten se käyttäytyy annetuissa tilanteissa. Toiminnallinen vaatimus voi olla joko käyttäjä- tai järjestelmävaatimus. vaatimusmäärittely; vaatimusten määrittely fi vaatimusten määrittely prosessi, jonka tavoitteena on selvittää ohjelmistolle asetettavat vaatimukset sellaisella tarkkuudella, että niiden perusteella voidaan kommunikoida eri osapuolille, millaisen ohjelmiston halutaan olevan Vaatimusten määrittely sisältää myös vaatimusten dokumentoinnin. verkkopalvelu fi verkkopalvelu; internetpalvelu; nettipalvelu en web service (1); online service; Internet service internetissä oleva multimedia- tai sisältökokonaisuus (esim. www-sivusto, portaali tai sähköinen asiointipalvelu), jolla on yksi tai useampi käyttöliittymä erilaisille laitealustoille ja jolla on jossain vaiheessa käyttäjinä ihmisiä eikä pelkästään koneita, laitteita tai muita teknisiä rajapintoja verkkopalvelun omistaja fi verkkopalvelun omistaja taho, jolla on kokonaisvastuu verkkopalvelusta ja sen toimivuudesta, palvelun ylläpidon ja kehittämisen resursoinnista sekä hyötytavoitteiden saavuttamisesta viitearkkitehtuuri fi viitearkkitehtuuri; referenssiarkkitehtuuri viitearkkitehtuuri on rajatun arkkitehtuurikokonaisuuden abstrakti toimittaja- ja toteutusneutraali rakenne 7/32

Viitearkkitehtuuri on esitys arkkitehtuurikokonaisuuden loogisista osista ja niiden välisistä suhteista. Sillä ohjataan arkkitehtuurisuunnittelua halutunlaiseen toteutusrakenteeseen. Viitearkkitehtuuri voi olla organisaation sisäinen, toimialaan liittyvä tai yleinen looginen rakennemalli. 5 Verkkopalvelun yleiset periaatteet ja reunaehdot Verkkopalvelut ovat nykyään jo osa arkipäivää eli palvelukanava muiden joukossa. Mm. tämän vuoksi verkkopalvelun tulee liittyä selkeästi organisaation toimintaprosesseihin sekä tavoitteisiin. Verkkopalvelulla tulee olla myös omat organisaation johdon hyväksymät tavoitteet, jotka tukevat organisaation toiminnan tavoitteita. Verkkopalvelun tulee toteuttaa organisaation strategiaa ja tehostaa sen toimintaprosesseja. Myös yli organisaatiorajojen ulottuvat strategiat ja kehittämisohjelmat tulee huomioida, kuten esimerkiksi Julkisen hallinnon asiakkuusstrategia: http://verkkojulkaisut.vm.fi/zine/9/cover# Verkkopalvelu voi synnyttää uudentyyppisiä palvelutarpeita ja riippuvuuksia (esim. asiakastuki, joka opastaa verkkopalvelun käytössä). Kehittämispäätöstä tehtäessä tulee siis ottaa huomioon palvelun ylläpidon vaatimat resurssit ja jatkokehitystarpeet sekä henkilöstön osaamis- ja koulutustarpeet. Osana päätöksentekoa on myös rahoitusmallista päättäminen sekä kustannus- ja hyötyanalyysin tekeminen. Verkkopalvelun suunnittelua ja toteuttamista edeltää yleensä myös konseptisuunnittelu, jossa palvelun omistaja määrittelee verkkopalvelun tehtävät, tavoitteet ja käyttäjät, sekä tarkastaa, että ne ovat organisaation yleisen toimintastrategian mukaisia (kts. luku 6.1 Konseptin määrittely). Tyypillisesti organisaatioissa pyritään ohjaamaan asiakkaat muista kanavista sähköisiin kanaviin kustannustehokkuuden lisäämiseksi sekä myös asiakkaan asioinnin joustavuuden parantamiseksi. Tästä johtuen palvelun johdon tulisi seurata palvelulle asetettujen vaatimusten toteutumista ja tehdä palvelun jatkokehittämistä koskevat linjaukset osana organisaation toimintaa ja kehittämistä. Seuraavaan listaan on koottu verkkopalvelun kehittämisen perusperiaatteet, joita suositellaan noudatettavaksi. 1. Tunnista, mitkä ovat käyttäjien tarpeet. Suunnittele palvelu näiden tarpeiden pohjalta. a. Käytä suunnittelussa apuna olemassa olevia tietoja käyttäjistä, käyttäjätehtävistä ja halutuista aikaansaannoksista ja käytettävyysvaatimuksista. b. Hyödynnä suunnitteluohjeistoja ja -standardeja. 2. Rakenna sähköinen palvelu, älä pelkkiä verkkosivuja! Palvelun on oltava osa toimivaa toiminta- ja/ tai asiointiprosessia. 3. Varmista palvelun yhdenmukaisuus organisaation strategian, tavoitteiden kanssa. Verkkopalvelun tulee myös noudattaa organisaation arkkitehtuuriperiaatteita ja linjauksia. 4. Huomioi palvelun toimintaympäristö ja siinä tapahtuvat muutokset. a. Selvitä organisaatiorajat ylittävät prosessit, palvelut ja tiedot sekä tietojärjestelmät ja verkkopalvelun liittymät niihin. b. Tarkasta palveluratkaisujen yhteensopivuus hallinnonalan muiden palveluiden, ratkaisujen sekä viitearkkitehtuurien kanssa. 5. Sovi palvelun omistajuudesta ja vastuista. Verkkopalvelun perustamisen ja kehittämisen tulee tapahtua osana organisaation laajempaa kehittämistä ja ennakointia pitkällä aikavälillä. 6. Selvitä milloin ja miten palvelua käytetään eri päätelaitteilla, kotoa tai julkiselta paikalta, eri kellonaikoina, tiedon haussa tai sen jakamisessa. 7. Suunnittele palvelusta mahdollisimman yksinkertainen ja helppokäyttöinen. 8/32

a. Käytä riittävästi aikaa ja tarvittaessa eri alueiden asiantuntijoita käytettävyyden, selkeyden ja esteettömyyden varmistamiseen. Edellytä asiantuntijoilta sitoutumista määritellyn käytettävyystason saavuttamiseen. b. Huolehdi siitä, että palvelu on suunniteltu eritasoisille ja erilaisille käyttäjille. c. Varmista palvelun esteettömyys noudattamalla verkkosisällön saavutettavuusohjeita, kts. WCAG:n ohje verkkopalvelujen esteettömyydestä (versio 2.0). http://www.w3.org/translations/wcag20-fi/ 8. Pidä myös palvelun sisältö ja ulkoasu yksinkertaisena ja selkeänä. Priorisoi palvelussa tarjottavat toiminnallisuudet ja sisällöt käyttäjän tarpeisiin perustuen. a. Mikäli joku toinen taho tarjoaa jo palvelussaan vastaavia tietoja tai toimintoja, linkitä sivut tarpeellisin osin. b. Ole johdonmukainen sivujen sisällön tai visuaalisten piirteiden suunnittelussa, mutta älä pakota kaikkia sivuja täysin samannäköisiksi. 9. Toteuta palvelu tarvittavan monen käytettävyystestauskierroksen avulla. Älä tee kerralla liian suuria kokonaisuuksia vaan pyri nopeisiin toteutuksiin ja kehitä palvelua jatkuvasti aidon käyttäjäpalautteen pohjalta edelleen. a. Muista kuitenkin suunnitella ja määritellä testattavat versiot huolellisesti turhan testaamisen ja kustannusten välttämiseksi. 10. Suunnittele palvelu riittävän avoimesti. Jaa tietoa avoimesti, kuitenkin tarvittava tietoturva ja tietosuoja huomioiden. 11. Huomioi lainsäädäntö ja sen asettamat vaatimukset verkkopalvelun suunnittelussa ja ylläpidossa (kts. liite 2 Lainsäädäntöluettelo.) 12. Sosiaalista mediaa voidaan hyödyntää verkkopalvelujen kehittämisessä tai verkkopalvelu voi linkittyä erilaisiin sosiaalisen median palveluihin. a. Huomioi sosiaalisen median hyödyntämisessä tietosuojakäytännöt. b. Huomioi myös, että hyödynnettäessä sosiaalisen median palveluita esteettömyysvaatimukset eivät aina kaikilta osin täyty. c. Materiaalia sosiaalisen median käyttämisestä julkisessa hallinnossa mm. osoitteessa: http://www.kansanvalta.fi/etusivu/tutkimusjakehitys/sosiaalisenmedianmahdollisuudethallinnol lepa 13. Määrittele jo suunnitteluvaiheessa, miten palvelua ylläpidetään ja jatkokehitetään sekä miten kehittämisessä otetaan käyttäjien palaute ja tarpeet huomioon. Lisätietoja mm. Iso-Britannian valtionhallinnon verkkopalvelun suunnitteluperiaatteet https://www.gov.uk/designprinciples. Suomen avoimen hallinnon toimintasuunnitelma http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/03_muut_asiakirjat/avoin_hallinto_toimintasuunnitel ma.pdf. 9/32

Kuva 2 Palvelun kehittämisen tarkistus- ja päätöspisteet 5.1 Verkkopalvelun tavoitteiden ja hyötyjen määrittely Verkkopalvelun hyötyjä tulee tarkastella kokonaisuuden näkökulmasta: asiakkaan, oman organisaation sekä muiden sidosryhmien kannalta. Yhteiskunnallinen hyöty on yhä useammin perusteltavaa julkisissa verkkopalveluissa. 5.1.1 Verkkopalvelun hyödyt asiakkaalle ja sidosryhmille Seuraavassa on kuvattu joitain verkkopalvelun tuottamia hyötyjä asiakas- ja sidosryhmänäkökulmasta: Verkkopalvelu mahdollistaa asioinnin ajasta ja paikasta riippumatta. Asiakkaalta vaadittu panos suhteessa saatuun palveluun vähenee (transaktiokustannus). - Helpompi, vaivattomampi, kustannustehokkaampi. Verkkopalvelu mahdollistaa vaivattoman asioinnin ja sen kautta voi seurata asioinnin etenemistä. Lisäksi verkkopalvelusta on mahdollista saada tukea tai lisätietoa asiointiin. Verkkopalvelun kautta on mahdollista osallistua päätöksentekoon ja (verkko)palvelujen kehittämiseen. Verkkopalvelun kautta palveluprosessit ovat läpinäkyvämpiä asiakkaalle. Verkkopalvelusta voidaan saada tarvittavaa avointa, luotettavaa ja ajantasaista tietoa. Verkkopalveluja suunniteltaessa on palvelukohtaisesti mietittävä niiden tuottamat hyödyt käyttäjälle ja tunnistettava mitkä ovat lisähyödyt verrattuna aikaisempaan tapaan saada palvelua. Esimerkiksi palvelun tuoma hyöty olla että asiakas voi asioida myös iltaisin ja viikonloppuisin. 10/32

5.1.2 Verkkopalvelun hyödyt organisaatiolle Verkkopalvelun avulla voidaan lisätä organisaation toiminnan tunnettuutta, vaikuttavuutta ja avoimuutta. Avoimuutta tukee esimerkiksi valmisteilla olevista asioista kertominen ja osallistumismahdollisuuksien tarjoaminen. Esimerkkejä avoimuutta tukevista verkkopalveluista ovat mm. www.otakantaa.fi www.kansalaisaloite.fi, www.kuntalaisaloite.fi www.avoinministerio.fi www.lausuntopalvelu.fi (valmistuu 1/2014). Verkkopalvelun avulla voidaan tarjota laajoja näkökulmia eri aiheisiin ja antaa mahdollisuus osallistua valmisteluun tai sen seurantaan. Laadukkaasti toteutetut verkkopalvelut vahvistavat käyttäjän positiivista mielikuvaa palvelun tarjoajasta. Verkkopalvelu antaa myös aiempaa monipuolisemman ja kattavamman käsityksen organisaation toiminnasta. Verkkopalvelun avulla voidaan lisätä asiakkaiden omatoimisuutta ja sitä kautta sitoutumista. Esimerkiksi asiakastiedot ovat paremmin ajan tasalla, kun asiakkaat pääsevät ylläpitämään tietojaan verkossa. Toimiva verkkopalvelu tuottaa myös kustannussäästöjä organisaatiolle. Esimerkiksi monikanavaisessa palveluntuotannossa verkon kautta tuotettu palvelu on yleensä yksikkökustannuksiltaan edullisin, kun perustamisinvestoinnit on tehty. Verkkoasioinnin suhteellinen osuus palveluntuotannosta on silloin hyvä mittari tuottavuudelle. Esimerkki: Iso-Britannian valtionhallinnon Performance Platform https://www.gov.uk/performance Investoinnin kannattavuutta tulee tarkastella tutkimalla palvelun kehittämisen ja sen ylläpidon kustannuksia suhteessa palvelusta saavutettavaan hyötyyn. Esimerkki: SADe-ohjelman kustannus- ja hyötyanalyysi http://www.vm.fi/vm/fi/05_hankkeet/023_sade/index.jsp Apuvälineenä kustannusten ja hyötyjen arvioinnissa voidaan käyttää esimerkiksi JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen -suosituksessa kuvattua hyötykartoitusta (JHS 171, liite 3 Kustannus-hyöty -analyysipohja). Verkkopalvelun perustamis- tai kehittämishankkeen arvioinnissa voi hyödyntää valtiovarainministeriön julkaisemaa yhteistä tietojärjestelmähankkeiden arviointikehikkoa, joka löytyy ohjeineen osoitteesta: https://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/03_muut_asiakirjat/20110527valtio/name.jsp 5.2 Verkkopalvelut osana kokonaisarkkitehtuuria ja palveluiden viitearkkitehtuureja Palveluita kehitettäessä ja suunniteltaessa on huomioitava julkisen hallinnon kokonaisarkkitehtuurin asettamat vaatimukset oman organisaation kokonaisarkkitehtuurivaatimusten lisäksi. Lisäksi pitää ottaa 11/32

huomioon erilaiset oman organisaation toimialaan/hallinnonalaan ja vastuualueeseen liittyvät kohde- ja muut arkkitehtuurit, kuten esimerkiksi sosiaali- ja terveyspalveluiden kohdealuearkkitehtuuri. Lisätietoja mm. JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen -suositus http://www.jhs-suositukset.fi/suomi/jhs179 Julkisen hallinnon yhteisen kokonaisarkkitehtuurin (JHKA) kuvaukset ja menetelmät https://www.yhteentoimivuus.fi/view/snav/arkkitehtuurimalli.xhtml Julkisen hallinnon sähköisten asioinnin viitearkkitehtuuri (SAVI) https://www.yhteentoimivuus.fi/view/asset/asset.singleview.xhtml?id=60126 5.2.1 Verkkopalvelu osana tiedonhallintaa Palveluita kehitettäessä ja suunniteltaessa on huomioitava organisaation tiedonhallinnan prosessit sekä tiedonhallinnan hallintamalli, erityisesti sisällönhallinnassa (asiakirjojen ja dokumenttien hallinta). Tietojen yhteensopivuus on olennainen vaatimus tietojen siirrolle yli organisaatiorajojen. Organisaation tulee lisäksi huomioida arkistolaitoksen vaatimukset materiaalien säilyttämiselle ja metatiedoille: onko arkistointivelvoitetta, missä arkistoidaan, jos arkistoidaan sekä miten arkistoidaan. Lisätietoja mm. JHS 143 Asiakirjojen kuvailun ja hallinnan metatiedot http://www.jhs-suositukset.fi/suomi/jhs143 JHS 176 Sähköisten asiakirjallisten tietojen käsittely, hallinta ja säilyttäminen http://www.jhs-suositukset.fi/suomi/jhs176 SÄHKE2-määräys http://www.arkisto.fi/fi/palvelut/julkisen-hallinnon-saehkoeiset-palvelut/saehke-maeaeraeykset 5.3 Palvelun johtaminen ja hallinta Palvelun hallinnassa on hyvä noudattaa organisaation palveluiden hallintamallia ja kytkeä palveluiden hallinta siten osaksi johtamisprosessia. Palvelun hallintamallin laatimiseen liittyvät mm. seuraavat tehtävät: Määrittele vastuualueet ja sovi roolit. - Määrittele ja sovi kuka on verkkopalvelun omistaja. Omistajan tulee tietää asiakkaiden tarpeet sekä tuntea palveluun liittyvät prosessit. - Rooleja on runsaasti ja ne vaihtelevat vaiheittain (kehittäminen, käyttöönotto, jatkuva palvelu). o Sovittava on, mikä rooli on prosessin omistajalla ja mikä substanssin edustajalla. o Sovittava on lisäksi, kuka on vastuussa mahdollisesta verkkopalvelun määrittelyn tai toteutuksen hankinnan kilpailuttamisesta. Määrittele ja sovi vastuut ja valtuudet sekä päätöksentekovaltuudet ristiriita- ja ongelmatilanteissa. Määrittele ja sovi palvelun kehittämisen ja toteuttamisen rahoitus. Määrittele kuka maksaa palvelun ylläpidosta ja kehittämisestä. Päätä palvelun hallintamallista ja kuvaa se. Laadi palvelulle elinkaarimalli ja -suunnitelma. 12/32

Ota hallintamalli käyttöön ja varmista hallintamallin mukaisten resurssien käyttäminen. Esimerkki verkkopalvelun hallintamallista: Verkkopalvelun hallinnan roolit: Palvelun omistaja Eri tahoista koottu kehittämis- tai ohjausryhmä Ylläpito Palvelun omistajan tehtävät ja vastuut: Vastaa palvelusta ja sen kehittämisestä ja resurssoinnista. Kehittämisryhmän/ohjausryhmän tehtävät ja vastuut: Vastaa palvelun toteutumisen seurannasta, palvelun kehittämisestä ja ohjaamisesta sekä ylläpidon ja kehittämisen seurantaprosessien noudattamisesta ja kehittämisestä. Tehtävät: a. Uusien toiminnallisuuksien vaatimusten käsittely ja hyväksyminen. b. Uusien vaatimusten käyttöönottojen projektointi. c. Palvelun toteutumisen seuranta. d. Osaamistarpeiden arviointi. Ylläpidon tehtävät ja vastuut Vastaa palvelun ylläpidosta, elinkaaren hallinnasta, teknisen toimivuuden seurannasta ja dokumentoinnista Tehtävät: a. Muuttuvat vaatimukset ja muutoksenhallinta. b. Elinkaarenhallinta. c. Dokumentaation ajantasaisena pitäminen. d. Teknisen toimivuuden (SLA) seuranta. e. Käyttäjätyytyväisyyden seuranta. f. Palvelun ylläpito ja poikkeustilanteiden käsittely. Lisätietoja mm. SADe-ohjelmassa syntyneet toimintamallit http://www.vm.fi/vm/fi/05_hankkeet/023_sade/index.jsp 5.3.1 Palvelun kehittämismallin valinta Palvelun kehittämistä suunniteltaessa on huomioitava eri kehittämismallit. Palvelun kehittämiseen liittyviä malleja on useita vesiputousmalleista erittäin ketterään kehittämiseen. Huomioitavia tekijöitä kehittämismallin valinnan yhteydessä ovat mm: Valinta esimerkiksi perinteisen vesiputousmallin kehittämisen ja ketterämmän menetelmän välillä tulee tehdä harkiten. Valinnan tulee perustua palvelun tulevaan käyttötarkoitukseen ja käyttäjiin sekä käyttötapoihin. Lähtökohtaisesti suositeltava malli (riippuen palvelun/organisaation luonteesta) perustuu jatkuvaan ja nopeasykliseen kehittämiseen. On huomioitava, että kehittäminen on jatkuvaa ja se jatkuu myös käyttöönoton jälkeen. Kehittämiselle on varattava riittävät resurssit (mm. henkilöt ja rahat) myös käyttöönoton jälkeiselle ajalle. Kehittäminen on osa kokonaisarkkitehtuurin hallintaa ja sitä koskevat julkisen hallinnon yleiset sekä organisaation omat kokonaisarkkitehtuuritavoitteet ja -linjaukset sekä periaatteet. 13/32

Kehitettävälle verkkopalvelulle asetetut vaatimukset tulee täyttyä ja verkkopalvelun laatu ja saavutettavuus tulee varmistaa eri kehittämisvaiheissa. Lisää kehittämis- ja toteuttamismallin valinnasta luvussa 6 Esiselvitys. 6 Esiselvitys verkkopalvelun kehittämisestä Ennen verkkopalvelun perustamispäätöstä ja toteuttamis- tai kehittämishanketta tulee tehdä esiselvitys. Esiselvitys koostuu mm. seuraavista tehtävistä ja selvityksistä: Määritä kehittämiskohteet eli mitä aiotaan kehittää. - Kts. esimerkiksi JHS 171 ICT-palvelujen kehittäminen: Kehittämiskohteiden tunnistaminen - suositus, http://www.jhs-suositukset.fi/suomi/jhs171 Selvitä organisaation palveluiden ja niiden kehittämisen nykytila. Kartoita verkkopalvelun kehittämisen ja ylläpidon kustannukset sekä sen tuomat hyödyt. - Selvitä mahdollisuus jakaa verkkopalvelun kehittämiseen liittyvät tavoitteet, tehtävät ja kustannukset muiden toimijoiden kanssa. Jos yhteishankintaan päädytään, se on huomioitava hankintaprosessissa. - Myös olemassa olevan palvelun kehittämisessä on suositeltavaa miettiä, onko mahdollista ottaa uusia toimijoita mukaan kehittämiseen. Tällöin on huomioitava hankintalainsäädäntö, sillä muutos voi vaatia uusia kilpailutuksia. Varmista kehittämisen rahoittaminen sekä kehittämisprojektin/hankkeen että jatkuvan ylläpidon aikana. Kartoita verkkopalvelun palveluun liittyvät muiden organisaatioiden palvelut tai kehittämisprojektit (l. sidosarkkitehtuurit). Selvitä myös onko olemassa julkisesti rahoitettua yhteiskäyttöistä alustaa, jota voisi käyttää asiointipalveluiden kehittämiseen. - Voidaanko hyödyntää olemassa jo olemassa olevia palveluita? - Voidaanko perustaa yhteisprojekteja muiden organisaatioiden kanssa? - Voidaanko oppia vastaavien palveluiden perustamisesta muissa organisaatioissa? Mieti, mitkä ovat palvelun kehittämisen tavoitteet eri näkökulmista. Arvioi mahdollinen olemassa oleva verkkopalvelu. - Tee tarvekartoitus eli selvitä nykyisten käyttäjien, sisäisten asiantuntijoiden tai haastatteluiden, kyselyiden tai workshopien avulla mikä nykyisessä palvelussa toimii ja mikä ei. - Vertaa vastaavia palveluita Suomessa ja ulkomailla mm. sisällön, toiminnallisuuden, käytettävyyden, ulkoasun ja teknologian suhteen. - Ota arvioinnissa huomioon mm. vaikutukset työntekijän tekemään työhön, työntekijöiden osaamisen tason arviointi, tietotekninen toimintaympäristö jne. - Voit arvioida myös nykyisen palvelun tasoa pyytämällä lausuntoa käytettävyyden ja käyttökokemuksen asiantuntijalta tai kyselyiden ja nykyisten käyttäjien haastatteluiden avulla. - Arvioinnissa on suositeltava käyttää myös Verkkopalvelujen laatukriteeristöä ja arviointityökalua. Laatukriteeristöä voi hyödyntää myös uuden verkkopalvelun suunnittelussa. Verkkopalvelujen laatukriteeristö: http://www.suomi.fi/suomifi/tyohuone/laatua_verkkoon/laatukriteeristo/ Verkkopalvelujen arviointityökalu: http://www.arviointityokalu.fi/ Analysoi markkinat ja tuotetarjonta. Markkinoilla on runsaasti valmisohjelmistoja tai -palveluita, jotka monissa tapauksissa tyydyttävät verkkopalvelulle asetetut vaatimukset. - Hyödynnä mahdollisuutta lähettää tietopyyntö toimittajaehdokkaille ennen tarjouskilpailua. Arvioi riskit ja laadi riskienhallintasuunnitelma. 14/32

Selvitä erilaiset toteutustavat. Palvelun toteutustavan tulee perustua organisaation strategioihin ja toimintasuunnitelmiin. Sen tulee lisäksi olla arkkitehtuurilinjausten mukainen. - Päätös siitä, ryhdytäänkö verkkopalvelua toteuttamaan itse vai ostetaanko palvelu tai osia palvelusta ulkoa, riippuu lisäksi organisaation toimintatavoista, omasta osaamisesta ja resursseista. o Useimmissa tapauksissa verkkopalvelun toteutus on yhdistelmä itse toteutetuista tai tuotetuista palvelun osista (esim. sisältö) ja hankituista/ulkoistetuista osista (esim. tekninen toteutus). Esimerkiksi ulkoasun suunnittelu voidaan hankkia organisaation o ulkopuoliselta ammattilaiselta, vaikka itse palvelu toteutettaisiinkin omin voimin. Silloinkin, kun palvelu annetaan ulkopuolisen tahon toteutettavaksi, organisaatiolla on vastuu tavoitteiden määrittelemisestä, palvelun ja prosessin suunnittelusta ja kehittämisestä ja linjauksista sekä käyttöönotosta. Toteuttava taho vastaa luonnollisesti toteutuksen laadusta, mutta organisaation tulee myös varmistaa, että laadulle asetetut vaatimukset täyttyvät. - Mikäli palvelu toteutetaan avoimella lähdekoodilla, noudatetaan JHS 169 Avoimen lähdekoodin ohjelmien käyttö julkisessa hallinnossa -suositusta. http://www.jhs-suositukset.fi/suomi/jhs169 - Avoimen lähdekoodin käytöstä lisätietoa myös SADe-ohjelman avoimen lähdekoodin toimintamallista: http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/03_muut_asiakirjat/sade_- _Avoimen_lhdekoodin_toimintamalli_-_v2012-12-19.pdf - Varmista ketteriä menetelmiä käytettäessä, että organisaatiolla on tarvittava osaaminen ja resurssit menetelmän käyttämiseen ja projektin läpiviemiseen (työmäärien arviointi ja hallinta, roolit ja vastuut, ketterän kehittämisen hallinta ja johtaminen). - Muista, että toteutustapa täsmentyy ja vahvistuu vaatimusmäärittelyn perusteella ennen hankintaa. Selvitä palvelun integrointi- ja tiedonsiirtotarpeet suhteessa olemassa oleviin tietojärjestelmiin. Ota huomioon integraatiotyössä esimerkiksi julkisen hallinnon XML-strategia ja julkisen hallinnon sähköisen asioinnin viitearkkitehtuuri. - Julkisen hallinnon XML-strategia: https://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/01_julkaisut/04_hallinnon_kehittaminen/405 33/name.jsp - Sähköisen asioinnin viitearkkitehtuuri (SAVI): https://www.yhteentoimivuus.fi/view/asset/asset.singleview.xhtml?id=60126 Huomioi, että esiselvityksen tuloksena voi syntyä myös päätös, että verkkopalvelua ei lähdetä toteuttamaan. Esiselvitysvaiheessa suositellaan hyödynnettäväksi suositusta JHS 172 ICT-palvelujen kehittäminen: Esiselvitys (http://www.jhs-suositukset.fi/suomi/jhs172). 6.1 Konseptin määrittely Verkkopalvelun konseptilla tarkoitetaan tässä yhteydessä verkkopalvelun palveluideaa ja konseptisuunnitelmalla näiden dokumentoitua kuvausta. Konseptisuunnitelmassa määritellään verkkopalvelun pääpiirteet ja tavoitteet perustuen organisaation vaatimuksiin ja verkkopalvelun käyttäjien tarpeisiin. Konseptisuunnitelma ohjaa palvelun kehittämistä sen koko suunnittelun, toteutuksen ja ylläpidon aikana, ja sillä pyritään varmistamaan yhtenäinen 15/32

käyttäjäkokemus verkkopalvelun sisällä sekä suhteessa muihin palveluntarjoajan verkkopalveluihin ja palvelukanaviin. Konseptisuunnitelma sisältää tyypillisesti seuraavia asioita: Tavoitteet - Mistä palvelun lisäarvo syntyy? - Mitä palvelulla pyritään konkreettisesti saavuttamaan organisaation ja käyttäjien näkökulmasta? Määritellään palvelun tärkeimmät toiminnallisuudet ja ratkaisut ja tehdään alustava suunnitelma siitä, mitä verkkopalvelussa voi tehdä. - Tavoitteena voi olla esimerkiksi asiointiprosessin sähköistäminen ja toiminnan tehostaminen, asiakaspalvelun laadun parantaminen, uuden palveluprosessin tuominen kansalaisten käyttöön jne. Käyttäjäryhmät ja niiden tarpeet - Kenelle palvelu on tarkoitettu ja miten käyttäjäryhmät hyötyvät palvelusta? - Miten käyttäjäryhmän tai -ryhmien toimintaa halutaan muuttaa? - Keitä palvelun käyttäjät ovat ja mitkä ovat heidän tarpeensa ja toiveensa suhteessa palveluun? - Käyttäjätiedon tulee perustua tutkittuun tietoon, kuten kyselyihin, haastatteluihin ja webanalytiikkaan. Pääväittämä ja arvolupaus - Realisoituuko tärkein ominaisuus käyttäjälle tärkeimmissä käyttötapauksissa jokaisella käyttökerralla? - Palvelun tärkeimmät ominaisuudet kiteytetään mahdollisimman tiiviisti, esimerkiksi yhdellä lauseella (motto). Suhde muihin palveluihin - Mikä on palvelun suhde muihin sähköisiin palveluihin? - Mikä on palvelun suhde muihin palvelu- tai viestintäkanaviin? - Mikä on palvelun ja sosiaalisen median suhde? - Kuvataan miten eri kanavien välisestä palvelukokemuksen yhtenäisyydestä huolehditaan. Ulkoasu ja graafinen ilme - Noudatetaanko jotain olemassa olevaa graafista ohjeistoa ja missä määrin? - Mietitään luodaanko jotain uutta ja mitä mahdollisella uudella ilmeellä tavoitellaan? - Onko tietoisena tavoitteena esimerkiksi vaikutelma selkeydestä ja luotettavuudesta vai onko tavoitteena houkuttelevuus ja trendikkyys? - Mikä on ulkoasun kattava teema yleisellä tasolla? Palvelun sisältö ja viestinnälliset ulottuvuudet - Minkälaista sisältöä palveluun pääpiirteittäin tuotetaan? - Kuvataan sisällön yleiset suuntaviivat ja tavoitteet. - Kuvataan eri sisältötyypit, kuten mahdolliset teksti-, kuva-, ääni- ja videosisällöt sekä niille asetetut rajaukset ja tavoitteet suhteessa organisaation ja käyttäjien tarpeisiin. - Kuvataan yleiset sisällöntuotannon periaatteet, laatuvaatimukset ja kriteerit. - Määritellään kuinka paljon aiemmasta palvelusta siirretään sisältöä uuteen sekä kuinka paljon ja minkälaista uutta sisältöä mahdollisesti luodaan. Konseptointi voidaan tehdä esiselvitysvaiheessa tai sen jälkeen. Muista, että konseptia tulee parantaa ja kehittää myös vaatimusmäärittelyn ja toteutuksen aikana. 6.1.1 Käyttöliittymäkonsepti Käyttöliittymän konseptisuunnitelma tehdään usein käyttöliittymämalleina (ns. rautalankamalleina) ja sen keskeiset ominaisuudet ja toiminnallisuudet kuvataan tai täsmennetään kirjallisesti. Suunnitelmassa kuvataan tyypillisesti ainakin seuraavat verkkopalvelun rakenteeseen liittyvät asiat: 16/32

tietorakenteen ja navigaation alustava hahmotelma. palvelun osakokonaisuuksien alustavat päänäkymät, kuten etusivu ja muita tärkeitä sivuston tasoja ja näkymiä. sivuston alustava sivupohjan rakenne sekä käyttöliittymälogiikan periaatteet. Käyttöliittymäkonsepti ei ole käyttöliittymäsuunnitelma, vaan tämän alustava hahmotelma. Luvussa 7.6 määritellään tarkemmin käyttöliittymäsuunnitteluun liittyviä suosituksia. 6.1.2 Ulkoasukonsepti Ulkoasun konseptisuunnitelma on palvelun graafisen ilmeen luonnos tai ehdotus. Sen yhteydessä voidaan lisäksi kuvata visuaalisen suunnittelun tavoitteita ja lähtökohtia, kuten esimerkiksi millaista mielikuvaa verkkopalvelun visuaalinen ilme välittää? miten visuaalinen ilme ilmaisee verkkopalvelun lajityypin? millaisia metaforia tai analogioita mahdollisesti käytetään? minkälaisiin kohderyhmiin ilmeellä pyritään vetoamaan ja millä perustein? Ulkoasun konseptisuunnitelmaa ei aina tehdä suunnittelun alkuvaiheessa, vaan ulkoasu suunnitellaan usein osana myöhempää suunnittelua konseptisuunnitteluvaiheen jälkeen. Ulkoasun suunnittelua voi joskus olla vaikea käytännössä erottaa käyttöliittymäsuunnittelusta, koska molemmat vaikuttavat merkittävästi toisiinsa. 7 Verkkopalvelun vaatimusten ja toiminnallisuuksien määrittely Vaatimusmäärittelyvaiheessa määritellään verkkopalvelun vaatimukset ja toiminnallisuus. Lisäksi kuvataan palveluun liittyvät toimintaprosessit, käsiteltävät tiedot (esim. tietomalli), keskeiset käyttötapaukset tai - skenaariot, yhteys muihin järjestelmiin sekä tehdään alustava testaussuunnitelma ja testitapaukset. Palvelulle asetettavat vaatimukset sisältävät toiminnallisten vaatimusten lisäksi myös käytettävyyden ja esteettömyyden vaatimukset (kts. luku 7.2 Verkkopalvelun käyttäjälähtöisyyden vaatimukset). Verkkopalvelun toiminnallisuuksien ja vaatimusten määrittely on hyvä tehdä omana suunniteltuna kokonaisuutenaan. Noudata organisaation omaa tai jotain yleistä projektimenettelyä sekä soveltuvia sovelluskehitysmenetelmiä. Huomioi, että valittu palvelun kehittämismalli vaikuttaa määrittelyn tuottamiseen. Esimerkiksi ketterissä menetelmissä vaatimusmäärittely tehdään alussa selvästi väljemmin kuin vesiputousmalli -tyyppisessä projektissa. Määrittely tarkentuu tällöin työn edetessä ja varsinainen määrittelydokumentti valmistuu usein vasta itse palvelun valmistuessa. Vaatimusten määrittelyn rinnalla tässä vaiheessa varmistetaan, että palvelun hallintamalli on määritelty ja sen mukainen resursointi on tehty. Lisäksi varmistetaan palvelun toimintalogiikan ja rakenteen suunnittelulla se, että suunniteltu palvelu tulee olemaan osa laadukasta ja toimivaa prosessia. JHS 173 ICT-palvelujen kehittäminen: Vaatimusmäärittely -suositusta on suotavaa noudattaa tässä vaiheessa (http://www.jhs-suositukset.fi/suomi/jhs173). 17/32

7.1 Toiminnallisten vaatimusten määrittely Palvelun vaatimuksien ja toiminnallisuuksien määrittelyssä tulee lähteä palveluprosessin kehittämisestä ja sen tukemisesta huomioiden sekä käyttäjien tarpeet että organisaation strategia että kokonaisarkkitehtuurin asettamat linjaukset ja vaatimukset. Mahdolliset tulevaisuuden tekniikat ja käyttötavat tulee ottaa huomioon suunnittelussa siten, että nyt toteutettava palvelu on kehitettävissä myös jatkossa. Liitteessä 1 on kuvattu toimintaympäristön kehittymiseen liittyviä tekijöitä. Huomioi tässä vaiheessa myös sisällön tuotantoon liittyvien suositusten asettamat vaatimukset. Seuraavassa listassa on kuvattu muutamia hyville verkkopalveluille ominaisia toiminnallisuuksia ja niihin liittyviä suosituksia: Palvelussa asioinnin on edettävä asiakkaan näkökulmasta kokonaisuutena, joka vastaa hänen ymmärrystään asiointiprosessista ja siihen kuuluvista osista. Palvelun tulee pystyä tarkastamaan käyttäjän syöttämät tiedot ja ilmoittamaan mahdollisista virheistä tai puutteista. Palvelussa tulee ilmoittaa selkeästi pakolliset syötettävät tiedot. Peruuttamattomiin toimintoihin tulee pyytää vahvistusta. Tietojen tulee olla löydettävissä helposti ja tehokkaasti ja palvelun on tarjottava erilaisia hakutapoja. Tietojen tulostaminen verkkopalvelusta tulee olla yksinkertaista. Verkkopalvelun pitää kyetä ehkäisemään ja sietämään virheitä sekä auttaa korjaamaan niitä. Verkkopalvelun tulee ilmoittaa käyttäjälle virheistä selkeästi. Palvelun tulee toimia moitteetta eri toimintaympäristöissä. Luvussa 7.6.1 on kuvattu tarkemmin eri päätelaitteiden huomiointi palvelun suunnittelussa. Liitteessä 1 on käsitelty toimintaympäristön kehittymisen huomioimiseen liittyviä tekijöitä. Palvelua tulee voida käyttää eri kielillä. Kielivaihtoehtojen esittäminen palvelussa tulee olla selkeää ja eri kieliversioiden ylläpito tulee varmistaa. Palvelun suunnittelussa ja sille asetettavien vaatimusten määrittelyssä tulee ottaa huomioon viranomaisia velvoittava lainsäädäntö. Verkkopalvelua koskevat toimintaprosessit tulee kuvata soveltuvin osin JHS 152 Prosessien kuvaus - suosituksen mukaisesti (http://www.jhs-suositukset.fi/suomi/jhs152). Verkkopalvelun vaatimusmäärittely tulee tehdä soveltuvin osin JHS 173 ICT-palvelujen kehittäminen: Vaatimusmäärittely -suosituksen mukaisesti (http://www.jhs-suositukset.fi/suomi/jhs173). Lisätietoja mm. Valtioneuvoston kertomus kielilainsäädännön soveltamisesta 2013 http://oikeusministerio.fi/fi/index/julkaisut/julkaisuarkisto/1371116573213.html Kuntien verkkoviestintäohje 2010 http://shop.kunnat.net/product_details.php?p=1693 7.2 Verkkopalvelun käyttäjälähtöisyyden vaatimukset Verkkopalvelu tulee suunnitella tukemaan eri käyttäjäryhmien ja yksittäisten käyttäjien todellisia tarpeita heidän lähtökohdistaan. Palvelua on kehitettävä perustuen todellisten käyttäjien kanssa toteutettuihin tutkimuksiin. Erilaisia tutkimusmetodeja ovat esimerkiksi käytettävyystestit, käyttäjähaastattelut, fokusryhmät, yhteisläpikäynnit sekä käyttökyselyt ja -palautteet. 18/32

7.2.1 Verkkopalvelun käytettävyys ja käyttökokemus Verkkopalvelun suunnittelussa on alusta lähtien varmistettava palvelun käytettävyys ja käyttökokemus, vaikka asioinnin erivaiheessa käytettäisiinkin eri palveluja, esimerkiksi yhteistä tunnistusratkaisua. Käytettävyydellä tarkoitetaan sitä, kuinka helppoa, miellyttävää ja tehokasta palvelun käyttö on todellisessa käyttökontekstissa. Se vaikuttaa siihen, kuinka hyvin käyttäjä saavuttaa todellisen tavoitteensa palvelussa. Kts. ISO 9241-1 -standardi: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=16883) Käyttökokemuksella tarkoitetaan sitä, millainen kokonaiskokemus ja tunne käyttäjälle muodostuu palvelua käyttäessään. Käyttökokemukseen vaikuttavat käytettävyyden lisäksi myös muun muassa palvelun ulkoasu, sisältö, luotettavuus, brändäys ja trendikkyys. Julkishallinnon palveluissa palvelun käytettävyys, luotettavuus ja sisällön laatu ovat ensisijaisen tärkeitä verrattuna käyttökokemuksen esteettisiin ulottuvuuksiin, kuten ulkoasuun tai trendikkyyteen. Käytettävyys ja käyttökokemus varmistetaan mm. seuraavilla tavoilla kehittämisprosessin (kts. kuva 2 Palvelun kehittämisen tarkistuspisteet) aikana: Selvitä käyttäjien tarpeet esimerkiksi käyttäjätutkimuksen avulla ja perusta suunnittelu todellisiin tarpeisiin ja tavoitteisiin. Ota samalla huomioon käyttökonteksti eli mihin ja miksi käyttäjä palvelua käyttää, kuten esimerkiksi luvan hakemiseen tai tietyn viranomaisen yhteystietojen etsimiseen. Ota mukaan suunnitteluun palvelun loppukäyttäjiä eri suunnitteluvaiheissa. Käy läpi jo karkeita suunnitelmia heidän kanssaan ja testaa niitä mahdollisuuksien mukaan (esim. demoversiot). Hyödynnä tarpeen mukaan asiantuntija-arviointia. Ohjaa suunnittelua saadun palautteen perusteella. Järjestä käytettävyystestaus mahdollisimman varhain, esimerkiksi palvelun prototyypillä tai viimeistään toiminnallisella palvelulla. Korjaa vähintään vakavat ongelmakohdat ennen käyttöönottoa ja laadi suunnitelma sellaisille korjauksille, joita ei heti voida tehdä. Kerää palautetta palvelun käytön aikana ja kehitä palvelua palautteen perusteella. Järjestä käytettävyystutkimus säännöllisin väliajoin. Huomioitavia asioita käytettävyyden arvioinnissa ja testauksessa: Käytettävyystestejä voidaan järjestää joko todellisessa käyttöympäristössä tai käytettävyyslaboratoriossa. Palvelun laadun ja sen osana käytettävyyden arviointi kannattaa aloittaa mahdollisimman varhain, koska mitä myöhemmin muutoksia tehdään, sitä kalliimmiksi ne tulevat. Arvioinnit ja testaukset tulee huomioida jo budjetoinnissa ja aikataulutuksessa. Käytettävyyden arvioinnin ja testien tuloksena löytyy käytännössä aina korjattavaa, joten varaa projektisuunnitelmassa aikaa ongelmien korjaamiseen. Mikäli projektin aikana ei ole taloudellisesti tai aikataulullisesti mahdollista tehdä useampaa arviointia tai testiä, tulee palvelu kuitenkin aina arvioida tai testata vähintään kerran. Tämä kannattaa yleensä tehdä hyvissä ajoin ennen julkaisua. Näin korjaukset saadaan tehtyä ennen julkaisua. Käytettävyyden arvioinnissa havaitaan usein ongelmakohtia, jotka tyypillisesti liittyvät esimerkiksi rakenteen toimivuuteen, asioiden ja termien ymmärrettävyyteen, vuorovaikutuselementtien loogiseen käyttöön ja ymmärrettävyyteen sekä asioiden löydettävyyteen. Myös graafinen ja muu ilmaisutapojen arviointi - esimerkiksi ikonit, muu kuvitus, värit, äänet - ovat osa käytettävyyden arviointia, silloin kun ne vaikuttavat käyttäjien suoriutumiseen palvelun käytössä. Arvioinnin tuloksena saadaan tavallisesti ongelmien luokitus niiden vakavuuden mukaan, selvitys ongelman syystä sekä perustellut korjausehdotukset. 19/32

Kuva 3 Käytettävyystutkimuksien käyttäminen eri vaiheissa palvelun suunnitteluprosessia. 7.2.2 Verkkopalvelun saavutettavuus ja esteettömyys Verkkopalvelun esteettömyydelle asetetut vaatimukset ja esteettömyyden tavoitetaso on määriteltävä viimeistään suunnitteluvaiheessa. Iso osa esteettömyyskriteereitä koskee verkkopalvelun ja käyttöliittymän teknistä toteutusta, joten varsinaista esteettömyysarviointia ei voi tehdä ennen kuin käyttöliittymän tekninen toteutus on valmis. Esteettömyysvaatimukset voidaan kuitenkin hyvin huomioida jo suunnitteluvaiheessa ja teknisessä toteutuksessa, kun noudatetaan hyviä suunnittelukäytäntöjä, käytettävyysperiaatteita sekä W3C:n esteettömyysohjeita (WCAG) ja teknisiä spesifikaatioita (HTML, XML, CSS). Suunnittelussa on huomioitava erikseen määritellyt erityisryhmät sekä olemassa olevat yleiset esteettömyys- ja saavutettavuusohjeet sekä lakien ja säädösten asettamat vaatimukset. Näitä ovat muiden muassa: - valmisteilla oleva EU:n direktiiviehdotus julkisen sektorin elinten verkkosivustojen saavutettavuudesta (COM(2012) 721) http://eur-lex.europa.eu/lexuriserv/lexuriserv.do?uri=com:2012:0721:fin:fi:html - WCAG:n ohje verkkopalvelujen esteettömyydestä, versio 2.0 http://www.w3.org/translations/wcag20-fi/ o Esteettömyydessä tulee pyrkiä vähintään WCAG 2.0 -ohjeen A-tason toteutumiseen. On kuitenkin huomattava, että A-tason toteuttaminen ei mahdollista sivujen esteettömyyttä kaikille käyttäjäryhmille. - Suomi.fi -sivuston saavutettavuuden linkkikokoelma: http://www.suomi.fi/suomifi/tyohuone/laatua_verkkoon/verkkopalvelun_saavutettavuus/index.ht ml. Huomioimalla verkkopalvelun esteettömyys edistetään palvelun käyttäjien yhdenvertaisuutta. Esteettömistä, helppokäyttöisistä ja selkeistä verkkosivuista hyötyvät kaikki käyttäjät, mutta erityisesti mm. - ikääntyneet henkilöt - henkilöt, joiden äidinkieli on muu kuin suomi - henkilöt, joilla on oppimis-, lukemis- tai kirjoitusvaikeuksia 20/32

- henkilöt, joiden näkö tai kuulo on heikentynyt - henkilöt, joilla on muita toiminnan rajoitteita. Eri toimintoihin, tilanteisiin ja ympäristöihin liittyvät saavutettavuusvaatimukset tulee määritellä. Verkkopalvelun tulisi olla saatavilla myös muilla kielillä (esim. ruotsi, saame, suomalainen viittomakieli) sekä luettavissa erilaisilla apuvälineillä (esim. ruudunlukuohjelma). Lähtökohtaisesti palveluissa on käytettävä selkeää kieltä. Palvelukohtaisesti on pohdittava, onko palvelu tai osia palveluista tarjottava selkokielellä eli sisällöltään, sanastoltaan ja rakenteeltaan yleiskieltä luettavammaksi ja ymmärrettävämmäksi mukautetulla kielellä niitä ihmisiä varten, joilla on vaikeuksia lukemisessa ja ymmärtämisessä - tai molemmissa (lähde: Selkokeskus). Palvelun käyttöaste on arvioitava ja palvelun toteutus suunniteltava sen perusteella. - Palvelun käyttöaste, eli kuinka paljon käyttäjiä ja milloin (esim. vuorokauden ajat, viikonpäivät) palvelulla oletetaan olevan, tulee arvioida. Tämä vaikuttaa ratkaisevasti palvelun toteutukseen ja ylläpitoon. - Käyttöasteen arvioinnissa voidaan hyödyntää tehtyjä käyttäjätutkimuksia ja käytön seurantaa. - Jos oletuksena on, että palvelua käytetään harvoin, palvelun omaksuttavuuteen on kiinnitettävä erityistä huomiota. Jos taas palvelua käytetään usein, korostuvat nopean ja sujuvan käytön asettamat vaatimukset. - Mahdollinen personointi on toteutettava harkitusti ja otettava huomioon siihen liittyvät riskit, esimerkiksi käyttäjien yhdenvertaisen tiedonsaannin vaarantuminen. Seuraavissa kappaleissa on kuvattu vaatimuksia käyttäjälähtöisesti suunnitellulle ja toteutetulle palvelulle: Palvelu tulee suunnitella riittävän avoimeksi ja läpinäkyväksi. Palvelun avoimuus ja läpinäkyvyys on varmistettava esimerkiksi tarjoamalla käyttäjälle tapa seurata oman asian käsittelyn etenemistä palvelussa. Palvelun käyttäjäryhmät ja roolit tulee olla määriteltyjä. Palvelun pääkohderyhmät sekä toissijaiset kohderyhmät tulee määritellä. Palvelun käyttäjät kannattaa ryhmitellä käyttäjäroolien ja osaamisen perusteella sekä sen mukaan, millaisia tarpeita heillä on palvelun käyttäjinä. - Palvelu suunnitellaan ja toteutetaan ensisijaisesti tukemaan pääkohderyhmiä tai muuten yleisiä käyttötarpeita. Toissijaisten ryhmien tarpeet huomioidaan, mutta siten, etteivät ne vaikeuta pääkäyttäjäryhmien tarpeiden täyttymistä. Myös huomioon otettavat erityisryhmät on määriteltävä, koska ne vaikuttavat palvelun toteutukseen. - Käyttäjäryhmien selvittämisessä ja määrittelyssä voidaan käyttää apuna esimerkiksi käyttäjätutkimuksia. Lisäksi voidaan ottaa yhteys erityisryhmiä edustaviin järjestöihin tai hyödyntää muiden tekemiä tutkimuksia ja tilastoja. o Tutkimusten (kts. luku 7.2.1) avulla voidaan saada selville tietoa eri käyttäjäryhmien mieltymyksistä ja tarpeista. o Usein myös asiakaspalveluhenkilöstöllä on arvokasta tietoa käyttäjien tarpeista. o Käyttäjäryhmien ja käyttötapausten ja -skenaarioiden määrittelyssä on suositeltavaa hyödyntää JHS 173 ICT-palvelujen kehittäminen: Vaatimusmäärittely -suositusta. Palvelun on oltava käytettävissä mahdollisimman kattavasti, eli ympäri vuorokauden kaikkina päivinä, jos mahdollista. Palvelussa tulee kertoa selvästi, minä aikoina palvelu on käytettävissä ja milloin saa henkilökohtaista palvelua. Jos mahdollista, käyttäjälle tulee osoittaa korvaava keino palvelun saamiseksi. - Usein palvelun käytön tukea tai muuta henkilökohtaista palvelua ei kuitenkaan ole tarkoituksenmukaista tarjota ympäri vuorokauden. Kansalaisen turvallisuuteen ja terveyteen liittyvien palveluiden tulee olla pääsääntöisesti käytettävissä aina, molemmilla kansalliskielillä. 21/32