Verkkopalvelun sisällöntuotanto

Transkriptio

1 Verkkopalvelun sisällöntuotanto 4. luento erikoistutkija Kirsi Silius tutkija Anne-Maritta Tervakari Tampereen teknillinen yliopisto 1

2 Teemat Reunaehtoja ja huomioonotettavia vaatimuksia Käyttäjien ja sidosryhmien tunnistaminen Käyttäjien ja sidosryhmien tarpeita ja tavoitteita Ansaintalogiikka Käyttäjien asiointiprosessien suunnitteleminen Miten saadaan tietoa käyttäjistä ja heidän tarpeistaan? Luennon tavoitteena on tuoda esille näkökulmia ja menetelmiä käyttäjien tavoitteiden saavuttamisen tukemiseen liittyvien prosessien analysoimiseen. 2

3 Reunaehtojen määrittely ennen teknistä määrittelyä Selvitettäviä ja määriteltäviä asioita: käyttäjät, heidän erityispiirteensä ja tarpeensa, verkkopalvelun tuottajan vaatimukset ja tarpeet esim. verkkopalvelun kustannustehokkuus, mahdollisten sidosryhmien tarpeet, asiointi- ja toimintoprosessit sekä käytön tavoite, informaatiosisältö, tekniset reunaehdot sekä taloudelliset yms. reunaehdot. Tavoitteena selvittää ketkä palvelua käyttävät, mitkä ovat palvelun käyttäjien tavoitteet, millaisissa tilanteissa ja millaisilla päätelaitteilla palvelua käytetään, mitä käyttäjät itse asiassa tekevät käyttäessään palvelua. syventää ja laajentaa synopsiksessa esitettyjä määritelmiä: mitä (aihe), kenelle (kohdeyleisö), miksi (tavoite) ja miten (käyttötapa). 3

4 Käyttökelpoisuuden ulottuvuudet Käytön sujuvuus Käytettävyysvaatimukset (usability requirements) Saavutettavuusvaatimukset (accessibility requirements): Verkkopalvelun hyödyllisyys (verkkopalvelun tulee soveltua tiettyyn käyttötarkoitukseensa) Tavoitteen saavuttamisen tukemiseen liittyvät vaatimukset, jotka riippuvat verkkopalvelun käyttötarkoituksesta (asiointi, tiedonhaku, viihtyminen, kuluttaminen jne.): Merkityksellisten sekä virtuaalisten että fyysisten toimintoja asiointiprosessien tukeminen Informaation laadukkuus kuten informaatioarkkitehtuuri, informaation esitystapa ja luotettavuus Verkkopalvelun käytön tuottama hyödyn eli lisäarvon (added value) toteutumiseen liittyvät vaatimukset (Silius ym. 2003) 4

5 Saavutettavuus Verkkopalveluiden käytön ongelmat voivat liittyä käytössä oleviin laitteisiin ja ohjelmistoihin tai käyttäjän fyysisiin tai kognitiivisiin toimintarajoitteisiin kuten esimerkiksi havaitsemiseen, motoriikan hallintaan, oppimiseen tai kielen ymmärtämiseen. Laajasti ajatellen liittyy mahdollisuuteen käyttää verkkopalvelua esim. näkö-, kuulo-, liikunta- ja CP-vammaiset sekä ihmiset, joilla on jokin muu pysyvä tai tilapäinen erityisongelma ikäihmiset, eri ikäiset lapset erilaiset päätelaitteet (esim. mobiililaitteet) ja käyttötilanteet (Esim. Turkki & Sinkkonen 2004) 5

6 Käytettävyys (usability) Haasteelliseksi käytettävyyteen liittyvän vaatimusmäärittelyn tekee se, että käytettävyyttä voidaan tarkastella monesta erinäkökulmasta: Käytettävyys suunnittelun tavoitteena: tavoitteena on systeemi, joka on hyödyllinen, jonka käyttö on helppo oppia (ja muistaa) ja jota on helppo ja miellyttävä käyttää. Gould ja Lewis vuonna Käytettävyys tuotteen ominaisuutena: johdonmukaisuus, hallittavuus, esitystapa, virheiden sieto, muistettavien asioiden määrä, tehtävän sopivuus, joustavuus ja opastus) Normanin vuonna 1991 esittämät viisi tuotteen ominaisuutta: käsitemalli, näkyvyys, kytkentä, palaute ja virheet. Nielsenin vuonna 1994 esittelemät kymmenen heuristista sääntöä. (Keinonen 1998) 6

7 Käytettävyys (usability) Käytettävyys tuotteen käyttöön liittyvänä ominaisuutena mainittuja ominaisuuksia ovat opittavuus, tehokkuus (nopeus ja virheiden määrä) ja miellyttävyys. Näkökulmaa edustavat esim. ISO DIS , Bennet 1984, Shackel 1991, Nielsen 1993 ja Jordan Käytettävyys käyttäjän kokemuksiin liittyvä ominaisuus: mm. käytön tyydyttävyys ja palkitsevuus, käytön havaittu hyödyllisyys, käytön henkinen ja fyysinen rasittavuus, turhautuminen sekä omistamiseen ja käyttöön liittyvä mielihyvä, aistillisuus sekä viihdyttävyys (vrt. Preece, Rogers & Sharp 2002, 19). 7

8 Käytettävyyden kontekstuaalisuus Käytettävyys voidaan ymmärtää eri tavoin objektiivisesti yleistettävä käytettävyysindeksi vai kontekstisidonnainen, ainutkertainen, subjektiivinen kokemus Käytettävyyteen vaikuttavat tekijät monentasoisia suhteellisen pysyviä tekijöitä: ihmisen psykologisiin ja fysiologisiin rakenteisiin liittyvät tekijät (muisti, havaitseminen, aistit) ja jotkin kulttuuriset tekijät (kieli, normit, tavat) kontekstitekijät: kohteena oleva tehtävä, käyttäjän yksilölliset kyvyt ja rajoitukset, käyttötila ja sen olosuhteet, käyttötilanne Suunnittelutyön varhaisessa vaiheessa onkin määriteltävä mitä saavutettavuudella ja käytettävyydellä tässä yhteydessä tarkoitetaan Seuraavaksi on tunnistettava verkkopalvelulle asetetut saavutettavuus- ja käytettävyysvaatimukset sekä dokumentoitava ne riittävän yksiselitteisesti. (Garret 2003, 40 59; Preece, Rogers & Sharp 2002, ) 8

9 Vaatimuksena lisäarvon tai edun tuottaminen Mitä erityistä hyötyä yleisellä tasolla voidaan tarjota toimijoille tietoverkkoja hyödyntämällä. tietoverkon käyttö tietyssä käyttötilanteessa tuo organisaatiolle ja ennen kaikkea asiakkaille. Arvioitaessa lisäarvoja tai etuja tarkastellaan verkkopalvelua suhteessa perinteiseen palveluun verkkopalvelua suhteessa käyttäjien toimintaan tavoitteen saavuttamiseksi henkilökohtaisessa kontekstissaan verkkopalvelun tarjoamaa ratkaisua johonkin reaalimaailman ongelmaan. Lisäarvon toteutuminen on voimakkaasti sidoksissa henkilön omaan kontekstiin Sama verkkopalvelu voi erota lisäarvoiltaan eri käyttäjien kesken. 9

10 Palvelun tuottajan tarpeet ja tavoitteet Tavoitteena lisäarvo ja kustannustehokkuus Syynä verkkopalveluun siirtymisen syynä saattaa olla myös toimintojen virtaviivaistaminen Toimintoja siirretään myös asiakkaan tehtäviksi, jolloin voidaan säästää henkilöstökustannuksissa Perustellaan usein myös sisällönhallinnan tehostumisella (sisällön tuottamisen, julkaisemisen, jakelun, poistamisen ja arkistoinnin ) digitaalista informaatiota on helppo tallentaa ja kopioida sekä käyttää uudelleen, siirrettävyys on nopeaa, sama informaatio soveltuu eri medialle ja siirtokanaville, informaation jakaminen on helppoa, muokkaus ja päivittäminen on helppoa informaation muuttuessa tai vanhentuessa jne. (Esim. Samela 2002, 140.) 10

11 Volere Requirements Specification Template PROJECT DRIVERS: 1. The Purpose of the Product 2. Client, Customer, Stakeholders 3. Users of the Product PROJECT CONSTRAINTS: 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS: 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements (Robertson & Robertson 2006) NON-FUNCTIONAL REQUIREMENTS: 10. Look and Feel 11. Usability and Humanity 12. Performance 13. Operational 14. Maintainability and Support 15. Security 16. Cultural and Political 17. Legal PROJECT ISSUES: 18. Open Issues 19. Off-the-shelf Solutions 20. New Problems 21. Tasks 22. Migration to the New Product 23. Risks 24. Costs 25. User Documentation 26. Waiting Room 27. Ideas for Solutions 11

12 Asiakas (käyttäjä) sekä hänen tarpeensa ja tavoitteensa on tunnettava Jos toteuttaa verkkopalvelun pelkkien asiakasta koskevien mielikuvien varassa, melko todennäköisesti onnistuu rajaamaan osan potentiaalisista asiakkaista ulkopuolelle (Turkki & Sinkkonen, 2004). 12

13 Kuka on asiakas tai käyttäjä? Henkilöt (ja tahot) jotka toimivat vuorovaikutuksessa verkkopalvelun kanssa tietyn tavoitteen saavuttamiseksi käyttävät verkkopalvelua suhteellisen usein. käyttävät verkkopalvelua harvoin tai välillisesti. jotka vaikuttavat verkkopalvelun käyttöönottoon jollakin tavalla tai ne henkilöt joiden omaan toimintaan verkkopalvelun käyttöönotto vaikuttaa jollakin tavalla. Sidosryhmät (stakeholders) = tahot tai henkilöt, joihin tässä tapauksessa verkkopalvelu jotenkin vaikuttaa Ongelma: sidosryhmät määritellään usein liian kapeasti huomioiden ainoastaan kaikkein ilmeisimmät sidosryhmät ja heidän vaatimuksensa liian väljästi, jolloin vaarana on vaatimusten määrittely liian yleisellä tasolla, jotta niitä kyettäisiin soveltamaan käytäntöön (Sharp, Finkelstein & Galal 1999.) 13

14 Sidosryhmien määrittely System Satellite stakesholder interact affect Baseline stakesholder (users,developers, legislators, decisionmakers) interact Satellite stakesholder Supplier stakesholder support products Client stakesholder (Sharp, Finkelstein & Galal 1999.) 14

15 Ansaintalogiikka Ansaintalogiikka tarkoitetaan loogista mallia tai suunnitelmaa, jolla palvelusta tai tuotteesta on tarkoitus aikaansaada kannattava osa liiketoimintamallia Ansaintalogiikka voi liittyä kustannussäästöihin, tuottavuuden lisääntymiseen, markkinoiden valtaamiseen tai asiakkaan sitouttamiseen Ansaintalogiikkoja voidaan tarkastella myös saatavan vastineen perusteella, jolloin tulot kertyvät esimerkiksi välityspalkkioista, mainos- tai ilmoitustuloista, kauppa- tai valmistushinnasta, liittymistai jäsenmaksuista (vrt. Rappa, M ) Asiakasta voidaan laskuttaa suoraan tai epäsuorasti kolmannen osapuolen kautta. Tuotteen tai palvelun osat voidaan hinnoitella erikseen tai yhtenä pakettina, maksu voi perustua kiinteään kuukausi maksuun tai käytön mukaisesti. (Hamel, G ) 15

16 Ansaintalogiikan kehittäminen Ansaintalogiikkaa mietittäessä täytyy tunnistaa mahdolliset myyntituloa tuottavat vastineet, jotka voivat liittyä sisällön tuotantoon, käytettyihin teknologisiin ratkaisuihin, tuotekehitykseen ja lopputuotteisiin tai liiketoiminnan eri prosesseihin. On pyrittävä tunnistamaan sellaiset tekijät, joista voidaan kerätä maksu ja josta ollaan valmiita maksamaan, kuten osallistumisesta (jäsenmaksu), näkyvyydestä (mainokset yms.), palvelusta sinänsä (käyttömaksu), sisältötuotteista tai konkreettisista tuotteista (maksu). Lisäksi verkkopalvelun käyttötilanteisiin saattaa palvelun tuottajan näkökulmasta liittyä useitakin potentiaalisia ansaintamahdollisuuksia esim. oheistuotteiden ja palveluiden myyntiä. 16

17 Ansaintalogiikka malleja Suunniteltaessa ansaintalogiikkaa verkkopalvelulle tulee ottaa huomioon erilaisia ansaintalogiikkamalleja, sillä yhden verkkopalvelun sisällä voi olla useita eri ansaintalogiikoita. Rekola & Rekola (2003) esittelevät kuusi erilaista ansaintalogiikkaa: suora ansainta, lupaukseen perustuva ansainta, välillinen ansainta, tuotokseen perustuva ansainta, osallistuva ansainta sekä tietoon perustuva ansainta. (Rekola, K & Rekola, H ) Lisäksi ansaintalogiikka voi perustua lahjoitukseen (Wikipedia) 17

18 Käyttäjien prosessien suunnitteleminen Ei riitä, että edetään parhaan tämänhetkisen tiedon mukaan ja otetaan huomioon ne asiat, jotka tunnetaan (Turkki & Sinkkonen, 2004). 25

19 Tietoa käyttäjistä ja käyttötilanteista Käyttötilanteiden ja käyttäjien tarpeiden määritteleminen yksiselitteisesti on haastavaa. on kehitetty lukuisia menetelmiä, joissa pyritään ottamaan todellinen käyttäjä tavalla tai toisella mukaan sovelluksen suunnitteluun. esim. "Joint Application Design", "user-centered requirements analysis", "user-centered design", "many participatory design techniques" ja "Contextual Design". (Holzblatt & Beyer, 1993.) Käyttäjiä ja heidän toimintaansa koskevaa tietoa voidaan koota useilla eri menetelmillä. Usein hyödynnetään useampaa menetelmää samanaikaisesti. Haastattelut ja kyselyt, joilla selvitetään käyttäjän käsityksiä ja mielipiteitä, tiedontarpeita ja asenteita. Havainnointi ja testaus, joissa käyttäjien toimintaa seurataan ja tulkitaan. Tarinat ja päiväkirjat, joilla kirjataan konkreettisia kokemuksia. Roolileikit eli simulaatiot, joilla simuloidaan ja varioidaan käyttötilanteita. (Esim. Sinkkonen ym. 2002, 24 30; Turkki & Sinkkonen 2004; Wiio 2004) 26

20 Tilannetutkimus (Contextual Inquiry) Menetelmän avulla kerätään informaatiota sovelluksen käyttökontekstista jo ennen suunnittelun alkamista erilaisten vaatimusmäärittelyjen pohjaksi. Hyödyntää etnografista menetelmää informaation kokoamisessa. käyttäjän havainnointi ja haastattelu todellisessa käyttökontekstissa todellisia (työ)tehtäviä suorittamassa. Etuja: helppo tarvittaessa kysyä käyttäjältä, mitä hän kulloinkin oli tekemässä ja miksi havainnoitsija ja käyttäjä voivat yhdessä saada selville sellaisiakin tarpeita, joita käyttäjä ei välttämättä osaa ääneen kertoakaan. (Esim. Holzblatt & Beyer, 1993; Preece ym. 1994, 661.). 27

21 Tietoa käyttäjiltä tarinoiden (skenaarioiden) avulla Skenaario on tarina, jolla on juoni ja "idea kuvaava esimerkinomaisesti konkreettisia episodeja järjestelmän toiminnoista. yleensä skenaarioina käytetään pieniä, rajattuja kuvauksia käyttötilanteista tarkoituksena kuvata yksi mahdollinen tapahtumapolku. Soveltuu hyvin tiedon kokoamiseen käyttäjiltä heidän tehtävistään ja käyttötilanteista ja niihin liittyvistä vaatimuksista. konkreettisia kuvauksia uusien monimutkaisesta ja abstraktisesta sovelluksesta. helpottavat käyttäjää ymmärtämään mistä oikein on kyse auttavat kiinnittämään vaatimusmäärittelyn todelliseen ympäristöön saadaan koottua käyttäjille tuttua terminologiaa hyödynnettäväksi lopullisessa verkkopalvelussa. Tarinoita kertoa myös sarjakuvina, elokuvina, multimedian avulla tai näytelmänä (Vrt. Preece, Rogers & Sharp 2002, ; Sinkkonen ym. 2002, ) 28

22 Tarinat informaation kokoamisen apuna Eläytymismenetelmä kerätä kokemuksia kuten toiveita, pelkoja tai haaveita erilaisista ilmiöistä tai tapahtumakuluista tässä ajassa tai tulevaisuudessa. käytetään nk. kehyskertomuksia alkuorientaationa ja pyydetään vastaajia ideoimaan ja kertomaan vapaasti niiden pohjalta Tarinat käyttäjien toiminnan hahmottamisessa Toimintatarinat kerätään tietoa käyttötilanteista sekä niihin liittyvistä tehtävistä, mahdollisuuksista ja rajoitteista sekä tavoitteista saadaan esille toiminnot, joita tuotteella tulee saada aikaiseksi Käyttötarinat miten asiat verkkopalvelussa tehdään uuden tuotteen avulla kuvaavat konkreettisia käyttötapahtumia ja niihin kerätään tavoitteellisten toimintojen alatavoitteet, tavoitteen muodostumisen aikaansaavat tekijät sekä tarvittava palaute, josta tiedetään siirtyä seuraavaan alatavoitteeseen. ( Sinkkonen ym. 2002, 24 30) 29

23 Tarinat käyttäjien toiminnan hahmottamisessa Navigoint imallit Toimintatarinat Käyttötarinat Paperiprotot Toimivat protot Tuotteet Käytettävyyden tarkistukset Toimintatarinat muunnetaan malleiksi, kuvauksiksi, protoiksi ja tuotteeksi. Lähde. Sinkkonen ym. 2002,

24 Scenario-Based Design Skenaariopohjainen suunnittelumalli. Lähde: Rosson & Carroll

25 Scenario-Based Design Skenaarioita voidaan hyödyntää varsin monella tavalla järjestelmän suunnittelutyön eri vaiheissa. Lähde: Rosson & Carroll,

26 Suunnittelun lähtökohtana asiakkaan prosessit Toiminnallisuudeltaan käyttökelpoisen verkkopalvelun suunnittelu vaatii käyttötilanteiden ymmärtämistä. Käyttötilanteiden ymmärtäminen taas edellyttää käyttäjän prosessien analysointi ja ymmärtäminen. Käyttäjien (ja eri sidosryhmien edustajien) prosessien mallintaminen on varsin toimiva keino käyttötilanteiden ymmärtämiseksi. Apuna mallinnuksessa toiminta- ja tapahtumatarinat eli skenaariot Käyttäjät, palvelun tuottajat sekä potentiaaliset sidosryhmien edustajat näkevät samaan asiaan liittyvät prosessit eri näkökulmista. Kun asiointiprosessi on jäsennetty eri toimijoiden näkökulmista, on helppo koota kuvaus siitä, mitä tapahtumia ja toimintoja ohjelmiston ja tietokannan tulee tukea. (Esim. Rosson & Carroll 2002; Wiio 2004.) 33

27 Suunnittelun lähtökohtana asiakkaan prosessit Keskeiset vaiheet yksinkertaistettuna 1.vaihe: tunnistetaan käyttäjät, 2. vaihe: tunnistetaan kaikille käyttäjille yhteiset pyrkimykset (verkkopalvelun käyttötarkoitus), 3. vaihe: mallinnetaan prosessi (tai prosessit), 4. vaihe: prosessien sisältämät tilanteet, joissa verkkopalvelu ja käyttäjä ovat tekemisessä keskenään käyttämiseen liittyvät tilanteet, 5. vaihe: tilanteisiin liittyvät tarpeet, 6. vaihe: sidosryhmien tarpeiden tunnistaminen (Wiio 2004) 34

28 Tavoitteena käyttötilanteiden ymmärtäminen 1. vaihe: tunnistetaan käyttäjät: tyypilliset käyttäjät, heidän ominaispiirteensä ja tarpeet käyttäjäprofiilit myös potentiaaliset käyttäjät 2. vaihe: tunnistetaan kaikille käyttäjille yhteiset pyrkimykset (verkkopalvelun käyttötarkoitus) 3. vaihe: mallinnetaan prosessi (tai prosessit), lähtökohtana yleisen tason prosessi mitä vaiheita ja tapahtumia asiakas kohtaa ennen kuin tavoite on saavutettu koko prosessin mallintaminen usein riittää jäsennys prosessia eteenpäin vievistä toiminnoista ja tapahtumista hyvä lähtökohta: miten ihmiset yleensä toimivat HUOM! Kaikkia prosessin vaiheita ei voida järkevästi ja tarkoituksenmukaisesti tukea verkon välityksellä tarjottavan palvelun avulla (Wiio 2004) 35

29 Tavoitteena käyttötilanteiden ymmärtäminen 4. vaihe: prosessien sisältämät tilanteet, joissa verkkopalvelu ja käyttäjä ovat tekemisessä keskenään käyttämiseen liittyvät tilanteet käyttäjän tukeminen tilanteissa mitä toimintoja ja informaatiosisältöjä tarvitaan, jotta käyttäjä etenisi kohden tavoitettaan 5. vaihe: tilanteisiin liittyvät tarpeet erilaisilla käyttäjillä voi olla erilaisia tarpeita liittyen käyttötilanteisiin voi vaatia jopa erilaisia käyttöliittymiä 6. vaihe: sidosryhmien tarpeiden tunnistaminen käyttäjäryhmiä, joihin käsiteltävä asia vaikuttaa jollakin tavalla palvelun tuottajan taholta käyttäjän (asiakkaan) taholta On huomioitava, että käyttäjät, palvelun tuottajat sekä potentiaaliset sidosryhmien edustajat näkevät samaan asiaan liittyvät prosessit eri näkökulmista (Wiio 2004) 36

30 Informaation jalostaminen edelleen Esimerkki olennaisesta käyttötapauksesta (Preece, Rogers & Sharp 2002, 231). Käyttäjä: kirjaston asiakas Toiminta: kirjaan lainaaminen Tapahtuma: Kirjan paikantaminen Käyttäjän toiminto käyttäjän tunnistautuminen kirjaa koskevien tietojen antaminen hakutulosten huomioinen poistuminen järjestelmästä Järjestelmän palaute käyttäjän tunnistaminen tunnistetietojen vaatiminen hakutulosten esittäminen järjestelmän sulkeutuminen 37

31 Informaation jalostaminen edelleen Esimerkki hierarkkisesta tehtäväanalyysista (Preece, Rogers & Sharp 2002, 232). 0. Lainaa kirjan kirjastosta 1. Mene kirjastoon 2. Selvitä haluamasi kirjan sijaintitieto 2.1. Mene työasemalle, missä voi käyttää kirjaston tietokantaa 2.2. Avaa hakutoiminto 2.3. Syötä hakutiedot 2.4. Poimi haluamasi kirja hakutuloksista 2.5. Huomioi kirjan sijaintitiedot 3. Mene oikean hyllyn luo ja nouda kirja 4. Mene lainauspisteeseen ja lainaa kirja Tavoite 0. Suorita Jos kirja ei sijainnutkaan oletetusta hyllyssä, suorita Tavoite 2. Suorita Jos kirja ei ole tiedossa, suorita

32 Esimerkki 0. Lainaa kirja kirjastosta Tavoite 0. Suorita Jos kirja ei sijainnutkaan oletetusta hyllyssä, suorita Mene kirjastoon 2. Selvitä kirjan sijainti 3. Mene hyllyn luo ja nouda kirja 4. Mene lainauspistee seen ja lainaa kirja Tavoite 2. Suorita Jos kirja ei ole tiedossa, suorita Mene työasemalle (tietokanta) 2.2. Avaa hakutoiminto 2.3. Syötä hakutiedot 2.4.Poimi kirja hakutuloksista 2,5,. Huomioi sijainti (Preece, Rogers & Sharp 2002, 232). 39

33 Lähteet: Hamel, G Leading the Revolution. Boston: Harvard Business School Press. Holzblatt, K. & Beyer, H. Making Customer-Centered Design Work for Teams [online]. Concord: InContext Enterprises, Inc., 1993 [viitattu ]. Saatavissa www-muodossa: <URL: >. Keinonen, T One-dimensional usability - influence of usability on consumers' product preference. Taideteollisen Korkeakoulun julkaisu A21. Helsinki: Taideteollinen korkeakoulu. Preece. J. & al Human computer Interaction. Workingham: Addisson-Publishing Company. Preece, J., Rogers, Y., & Sharp, H Interaction design: Beyond human-computer interaction. New York: John Wiley & Sons. Rappa, M Managing the Digital Enterprise [online]. Raleich (NC.): North Carolina State University, 2007 [viitattu ]. Business models on the web. Saatavissa www-muodossa: <URL: >. Rekola, K & Rekola, H Palvelukeskeisten tuotteiden kehittäminen teollisuusyrityksissä. Helsinki: Teknologiateollisuus ry. 40

34 Lähteet Robertson, J. & Roberston, S The Volere Requirements Specification Template [online]. London: The Atlantic System Guil Limited, 2006, [viitattu ]. Edition 11. Saatavissa www-muodossa: <URL: >. Rosson, M. B. & Carrol, J. M. Scenario-Based design [online]. Blacksburg VA: Virginia Polytechnic Institute and State University, 2002 [viitattu ]. Saatavissa pdf-muodossa: <URL: >. Myös teoksessa: J. Jacko & A. Sears (Eds.) The Human- Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications. Mahwah (NJ.):Lawrence Erlbaum Associates, 2002, pp Samela, J Verkkosisällön hallinta. Helsinki: Edita Publishning Oy. 41

35 Lähteet Sharp, H., Finkelstein, A. & Galal, G. Stakeholder identification in the requirements engineering process [online] [viitattu ]. Saatavissa pdf-muodossa <URL: >. Proceedings of the 10th International Workshop on Database & Expert Systems Applications on the 1-3 September 1999 in Florence. Italy, ISBN: Silius, K., Tervakari, A-M., Kaartokallio, H. & Yritys, K. Tieto- ja viestintätekniikka-avusteisen opetuksen käyttökelpoisuuden arviointimalli [online]. Espoo: Suomen virtuaaliyliopiston kehittämisyksikkö, 2003 [viitattu ]. Suomen virtuaaliyliopiston e-julkaisuja nro 9. Saatavissa pdfmuodossa: <URL: > ISBN Sinkkonen, I. ym Käytettävyyden psykologia. Helsinki: Edita Oyj. Turkki, L. & Sinkkonen, I. Esteetön vai käytettävä? [online]. Helsinki: Adage Oy, 2004, julkaistu , [viitattu ]. Saatavissa wwwmuodossa: <URL: >. Wiio, A Käyttäjäystävällisen sovelluksen suunnittelu. Helsinki: Edita Publishing Oy. 42