Re: Paatti-projektin vaatimusmäärittelyn hahmotelma

Kirjoittajan mukaan: Jukka-Pekka Santanen <jukka-pekka.santanen_at_mit.jyu.fi_at_localhost>
Päiväyksen mukaan: Thu, 23 Feb 2012 14:43:12 +0200
Terve!

Tein ryhmän laatimista kehitettävän sovelluksen toiminnallisista 
vaatimuksista huomiota. Toiminnallisilla vaatimuksilla tarkoitetaan
siis sovelluksen käyttäjille, muille ohjelmistoille ja ohjelmiston
sisäisille rajapinnoille määriteltyjä tietoihin ja toimintoihin
liittyviä vaatimuksia.

Kirjasin huomioistani suurimman osan kysymysten muotoon. Nimittäin
niistä osaan tarvitaan tilaajan edustajien mielipide, osa lienee
tarpeettomia tai tavoitteita tarkentavia huomioita sekä osa liittyy
käytettyihin käsitteisiin ja/tai esitystavan yksikäsitteisyyteen.

Tavoitteita ja niistä johdettuja vaatimuksia on sen verran paljon, 
ettei mitenkään niistä kaikkia ehditä toteuttaa projektissa. Osa
vaatimuksista saattaa olla siten järkevä jättää aika yleiselle
tasolle, joita projektin jälkeisessä jatkokehityksessa voidaan
tarvittaessa tarkentaa käyttäjiltä ja kehittäjiltä kerätyn tiedon 
ja kokemusten pohjalta.

> Toiminnalliset vaatimukset
> 
Ainakin käsitteet (vuorovaikutus)tapahtuma ja tehtävä tulee kuvata 
jossakin. Käsittääkseni siis tapahtumat koostuvat tehtävistä? Onko
erikseen tehtävätyyppejä vai ovatko ne samat tapahtuman muokkauksen
puunäkymässä olevia ''komponenttityyppejä''?

Voiko yhdellä ryhmällä olla useampia tapahtumien joukkoja, joita
tilaajan edustajat taisivat kuvata sanalla interventio. Voiko siis 
ryhmän ja/tai yksittäisen henkilön kuntoutuksen eri vaiheille olla 
erilaisia ''kuntoutussarjoja''? Kun siis kuntoutettava on saatu
hieman parempaan ''kuntoon'', hänelle voidaan määrittää seuraava
''kuntoutusaskel''. Liittyvätko mahdolliset kuntoutussarjat aina
tiettyyn henkilöryhmään (voidaan seurata tietyn ryhmän etenemistä)
vai siirretäänkö henkilöitä heidän edetessään ryhmästä toiseen?

Kannattaisiko yksittäiselle henkilölle määriteltävät tapahtumat
(tai kuntoutussarjat) ajatella ryhmälle, johon kuuluu vain yksi
kuntoutettava. Yhden henkilön ryhmään ilmeisesti sisältyy joka
tapauksessa useampi henkilö, koska tutkijoita, ohjaajia ja/tai
omaisia tulee liittää yksittäiseen henkilöön eri käyttöoikeuksin.
Tuolloin kyseessä jo onkin ryhmä, ja ryhmän kautta useamman
kuntoutettavan ja yhden kuntoutettavan tapahtumien ja tehtävien
hallinta sekä tulosten esittäminen voitaisiin hoitaa yhtenevällä
tavalla.

Suosittelen kirjattavan vaatimukset mieluummin muotoon ''Tutkijan 
käyttöliittymällä voi tehdä'' tai ''Hallintanäkymässä voi tehdä'',
sillä ''Tutkija voi tehdä'' kyseiset toimenpiteet muutenkin kuin
kyseisellä käyttöliittymällä. Lisäksi näkymien käyttöoikeudet
voisi kuvata erillisillä toiminnallisilla vaatimuksilla, jolloin
riittäisi muokata käyttöoikeusvaatimuksia pahimmillaan yksittäisen 
roolin näkymien kaikkien vaatimusten sijaan.

> * Tutkijan käyttöliittymän vaatimukset
>   o Tehtävien hallinta
>
Onko ajatuksena koota tutkijakohtaisesti tai kaikkien tutkijoiden
käyttöö jonkinlainen tehtäväkirjasto, josta poimitaan tehtäviä
tapahtumiin? Toinen mahdollisuus on määrittää ensin tapahtuma, 
johon poimitaan tehtävätyyppejä tai valmiita tehtäviä joistain
muista tutkijan (tai toisen tutkijan) tapahtumista.

>     + Tutkija voi lisätä yksittäisiä tehtäviä syöttämällä tehtävän tiedot.
>     + Tutkija voi muokata yksittäisen tehtävän tietoja.
>
Valitaanko jokin tehtävätyyppi tai ''komponentti'' ensin ja
sen jälkeen kirjataan tehtävään yksilöivää ja kuvailevaan
metatietoa?

>     + Tutkija voi poistaa yksittäisen tehtävän, jos sitä ei ole liitetty
>       yhteenkään tapahtumaan.
>
Onko poistaminen fyysistä ja/vai tulisiko tehtävään liittää tila,
kuten suunnitteilla, aktiivinen, vanhentunut ja poistettu?

>     + Tutkija voi määrittää tehtävän vastausvaihtoehdoista ne, jotka 
>       aiheuttavat automaattisen hälytyksen.
>
Onko hälytys aina tehtäväkohtainen vai vaatiiko se tehtävän olevan
tietyssä tapahtumassa? Periytyykö siis tehtävään kirjattu hälytys 
muihinkin ko. tehtävän sisältäviin tapahtumiin?

>   o Tapahtumien hallinta
>     + Tapahtumien lisääminen on mahdollisimman loogista ja yksinkertaista.
>
Pystyisikö vaatimuksen esittämään yksikäsitteisemmin? Yo. muodossa
on hankala mitenkään todeta vaatimuksen toteutumista.

>     + Tapahtuman asetuksista voidaan määritellä mahdollisen äänihälytyksen 
>       alkamisajankohta.
>     + Tapahtuman asetuksista voidaan määritellä mahdollisen tekstihälytyksen
>        alkamisajankohta.
>
Nämä eivät liene hälytyksiä, vaan muistutuksia. Kuntoutettavaa
siis muistutetaan tehtävän suorittamisesta. Käsite hälytys
kannattaisi mielestäni varata kiireelliselle tilanteella, jossa 
kuntoutettavan jostakin toiminnosta tai toimimattomuudesta johtuen
tulee saada jokin ohjaaja tai tutkija (henkilökohtaisesti tai
viestintävälineiden kautta) paikalle.

Kannattaako ääni- ja tekstimuistutusta käsitellä erikseen? Voisiko
muistutus tulla mobiililaitteen käyttäjän puhelimesta valitsemalla
tavalla. Esimerkiksi, jos käyttäjä on asettanut kännykän hiljaiselle, 
voisi muistutus tulla värinän muodossa.

>     + Tutkija voi muodostaa tehtävistä tapahtumia puutyökalun avulla.
>
Suosittelen vaatimuksen jakamista useammaksi, ts. ainakin lisääminen, 
järjestäminen ja poistaminen voisivat olla omia vaatimuksiaan. 
Pienempiin vaatimuksiin jakamalla voidaan useampi vaatimus todeta 
toteutetuksi, testatuksi ja hyväksytyksi. Muuten useita vaatimuksia
jää tilaan ''osittain toteutettu''.

>     + Tutkija voi muokata tapahtumia puutyökalun avulla.
>
Mitä tietoja ja toimintoja muokkaukseen sisältyy?

>     + Tutkija voi poistaa itse määrittämiään tapahtumia.
>
Onko tapahtumien poistaminen fyysistä vai tilatieto? Mitä tapahtuu 
kuntoutettavien suorittamille tapahtumilla ja niiden tiedoille?

>     + Tapahtumasta pääsee käsiksi tapahtumaan liittyvään suoritedataan.
>
Suoritedataankin lienee tarvetta päästä, mutta eikö tarvita myös
jonkinlaisin yhteenvetoja ryhmien ja henkilöitten tapahtumien
suorittamisesta?

>   o Ryhmien hallinta
>     + Tutkija voi lisätä tutkittavia itse määrittämiinsä ryhmiin.
>
Eikö tule pystyä poistamaankin tutkittavia ryhmistä? Mitä tällöin
tapahtuu mahdolliselle tutkittavan tapahtumista kerätylle tiedolle?

>     + Tutkija voi muokata tutkittavalle asettamiaan ryhmäjäsenyyksiä.
>     + Tutkija ei saa nähdä muiden kuin määrittämiensä ryhmien nimiä ja 
>       aikatauluja kalenterissa.
>
Tarkoitetaanko vaatimuksessa ryhmien ja/vai ryhmiin kuuluvien 
henkilöiden nimiä? Eikö omiin ryhmiin kuuluvien henkilöiden
tapahtumien sijoittumisen ajallisesti tulisi nähdä, muttei 
tapahtumien tarkempia tietoja? Pitäisikö pystyä näkemään siitä, 
kuka tutkija vastaa kyseisestä tapahtumasta?

>     + Tutkija voi lisätä tapahtumia määrittämilleen ryhmille.
>     + Tutkija voi poistaa tapahtumia määrittämiltään ryhmiltä.
>
Nämä lienevät nimenomaan tapahtumia, mutta liittävätkö ne johonkin
kuntoutussarjaan?

>     + Päällekkäiset tapahtumat näyttävät varoituksen uuden tapahtuman 
>       lisääjälle.
>     + Tutkija voi lähettää viestejä määrittämilleen ryhmille. 
>
Mitä viestit ovat käytännössä? Näkyvätkö ne sovelluksessa vai
ovatko ne sähköposteja ja tekstiviestejä?

>   o Tutkittavan hallinta
>     + Tutkija voi lisätä tapahtumia tutkittavan kalenteriin.
>     + Tutkija voi poistaa lisäämiään tapahtumia tutkittavan kalenterista.
>
Jos olisi käytössä yhden tutkittavan ryhmiä, nämä vaatimukset ovat
samoja kuin ryhmän vaatimukset.

>     + Tutkittavan suorittamat tapahtumat näkyvät korostettuina tutkittavan 
        kalenterissa.
>     + Tutkija voi tarkastella tutkittavan suorittamista tapahtumista 
>       kerättyä dataa sekä tekstuaalisessa että graafisessa muodossa.
>     + Tutkija voi lähettää viestejä tutkittavalle.
>     + Tutkija voi määrittää yhteyshenkilön hälyttäviä tilanteita varten. 
>
Eikö nämä vaatimukset tulisi voida liittää myös ryhmään? Jos
yksittäisiä henkilöitä käsiteltäisiin ryhmänä, yo. vaatimukset
pätisivät myös ryhmälle.

Teidän kannattaa pohtia tietojärjestelmän käyttäjien roolit, ts.
millaisia erilaisia käyttöoikeuksia tarvitaan eri tietoihin ja
toimintoihin? Yhteyshenkilö voisi olla joko rooli tai ryhmään
kuuluviin henkilöihin (kuten kuntoutettavat, tutkijat, ohjaajat 
ja omaiset) liitettävä ominaisuus. Saattaahan olla tarvetta myös
tilanteelle, jossa kuntoutettavien ryhmä toimii pääosin omillaan,
ja hälytykset lähetetään jollekin kuntoutettavista (kuten vaikkapa
vertaistukiryhmät).

>   o Tutkija voi muokata harjoituksen siirtämiseen tai keskeyttämiseen 
>     käytettävien syiden listaa.
>
Tarkoittaako harjoitus tapahtumaa, tehtävää, niitä molempia vai
jotain muuta? Onko vaatimus tehtävä-, tapahtuma- ja/vai
kuntoutussarjakohtainen? 

> * Tutkittavan käyttöliittymän vaatimukset
>
Tämän kokonaisuuden vaatimukset lienee pääosin poimittu Tabu-projektin 
laatimista vaatimuksista. Onko tarkoitus toteuttaa sovellus pääosin
painikepohjaisena, vai voisiko ainakin osassa tehtävistä ohjain olla
jokin muukin? 

>   o Ulkoasu
>     + Näkymien yleiset vaatimukset
>        # Tutkittavan käyttöliittymä on selkeä ja yksinkertainen.
>        # Näkymissä käytetään isoja ja selkeitä toimintopainikkeita.
>        # Näkymiin vieviin painikkeisiin on lisättävä yksinkertaiset 
>          kohdetta kuvaavat kuvakkeet.
>        # Lokalisointi ei riko käyttöliittymän asettelua.
>
Viittaako lokalisointi käytettyyn kieleen ja/vai mobiilialustaan?

Kuntoutettavan käyttöliittymän kieli varmaankin määritellään 
tapahtumien ja tehtävien määrittelyssä, ts. tältä osin eri kielten
kuntoutussarjat tulee toteuttaa erillisten tapahtumien kautta.
Tulisiko tutkijan käyttöliittymässä varautua useampaan kieleen
jotenkin?

>      + Päänäkymän vaatimukset
>        # Seuraava tapahtuma ilmaistaan painikkeen avulla.
>        # Tapahtumanäkymään päästään painamalla seuraavan tapahtuman 
>          painiketta.
>        # Seuraavan tapahtuman kuvaus ilmaistaan tekstimuodossa.
>        # Seuraavan tapahtuman kuvaus ilmaistaan kuvakkeella.
>        # Seuraavan tapahtuman yhteydessä ilmaistaan aika sen alkamiseen.
>        # Suorittamattomiin tapahtumiin tulee päästä painikkeen avulla.
>        # Tapahtuman alkamisesta ilmoitetaan äänihälytyksellä.
>        # Tapahtuman alkamisesta ilmoitetaan tekstipohjaisella hälytyksellä.
>        # Tapahtuman päättymisestä ilmoittaan äänihälytyksellä.
>        # Tapahtuman päättymisestä ilmoitetaan tekstipohjaisella hälytyksellä.
>
Nämä eivät liene hälytyksiä, vaan muistutuksia. Kuntoutettavaa
siis muistutetaan tehtävän suorittamisesta. Käsite hälytys
kannattaisi mielestäni varata kiireelliselle tilanteella, jossa 
kuntoutettavan jostakin toiminnosta tai toimimattomuudesta johtuen
tulee saada jokin ohjaaja tai tutkija (henkilökohtaisesti tai
viestintävälineiden kautta) paikalle.

Kannattaako eri tavoilla suoritettavia muistutustapoja käsitellä 
erikseen? Voisiko muistutus tulla mobiililaitteen käyttäjän 
puhelimesta valitsemalla tavalla. Esimerkiksi, jos käyttäjä on 
asettanut kännykän hiljaiselle, voisi muistutus tulla värinän 
muodossa.

>        # Suoritettavana olevan tapahtuman näkymä aktivoituu sille 
>          määritellyn aloitusajan mukaisesti.
>      + Tapahtumanäkymän vaatimukset
>        # Tapahtuman alkamisajankohta esitetään muodossa hh:mm.
>
Eikö tarvita myös päivämäärä? Liittyykö näkymä ainoastaan tulevaan
lähitulevaisuuden tapahtumaan vai tarkastellaanko sillä myös
menneiden vuosien tai seuraavan vuoden tapahtumia?

>        # Tapahtuman kokonaiskesto esitetään tunteina ja minuutteina.
>        # Tapahtumien tyypit erotellaan toisistaan kuvakkeiden tai värien 
>          avulla.
>        # Tutkittava voi jättää tapahtuman väliin valitsemalla syyn 
>          erillisen painikkeen avulla.
>        # Tutkittava voi siirtää tapahtumaa sen alkamisajankohtana 
>          erillisen painikkeen avulla.
>        # Tutkittava voi keskeyttää tapahtuman suorituksen erillisen 
>          painikkeen avulla.
>        # Tapahtuman kuvauksen yhteydessä esitetään tapahtuman kokonaiskesto.
>      + Tehtävien yleiset vaatimukset
>        # Tehtävätyyppi ilmaistaan kuvakkeen avulla.
>        # Tehtävätyyppi ilmaistaan tekstimuodossa.
>
Käsitettä ''tehtävätyyppi'' ei mainita aiemmin vaatimuksissa. Onko 
tehtävätyyppi sama kuin puurakenteeseen valittavat komponentit vai
voiko samasta komponentista muodostaa ryhmään tai tutkimukseen
liittyviä tutkijoille tai kuntoutettaville tuttuja tehtävätyyppejä?

>    o Tapahtumien suorittaminen
>      + Tapahtuman suorittaminen alkaa oman voinnin arvioinnilla.
>      + Tapahtuman suorittaminen päättyy oman voinnin arviointiin.
>
Eikö tutkija tapahtumaa määritellessään valitse arviointitehtävän
haluamaansa kohtaan tehtäväpuussa? Kannattaako siis kiinnittää
arviointien olevan _aina_ tapahtumien alussa ja lopussa? 

>      + Tehtävätyökalujen käyttömääristä pidetään kirjaa.
>
Mitä tällä tarkoitetaan? Vainko tehtävätyyppien käyttömääriä
kirjataan tietokantaan?

>      + Suoritetusta tapahtumasta lähetetään ilmoitus vastaavalle tutkijalle.
>      + Lykätystä tai keskeytetystä tapahtumasta lähetetään ilmoitus 
>        vastaavalle tutkijalle.
>
Ei kai tapahtumasta lähetetä ilmoitusta, vaan kirjataan siitä
tieto tietokantaan? Eikö vain hälytyksistä kannata lähettää
välittömästi tieto tutkijalle, ohjaajalla ja/tai omaiselle?

Kuka on vastaava tutkija? Onko se rooli vai tutkijaan liitettävä
ominaisuus? Voiko heitä olla useampia?

>      + Tapahtuman lykkääminen tai siirtäminen lisää tapahtuman 
>        "rästilistaan".
>
Siirretäänkö tässä mitään minnekään, vaan suorittamattomat
tapahtumat esitetään kuntoutettavalle ja/vai tutkijalle
erillisessä näkymässä?


Uupuuko vaatimuksista vielä jotain ohjelmaosiota koskevia? Miten
tapahtumat päivitetään kuntoutettaville? Lähettääkö palvelin
päivityksiä tarvittaessa vai kysyykö mobiilisovellus päivityksiä?
Suoritetaanko palvelinpäässä jotain toiminnallisuutta? Mitä
tietoja ja toimintoja halutaan tarkastella tutkijaan, ryhmiin ja
kuntoutettaviin sekä tapahtumiin ja tehtäviin liittyen? 

Terveisin,
                jukka-pekka

P.S. Saako muuten ajatuskarttaa jotenkin näppärästi jaettua
     useammamaksi kuvaksi joko selaimella tai ennen verkkoon
     siirtämistä. En saanut tulostettua JPEG-kuvaa siten, että
     tekstit olisivat olleet riittävän suuret luettavaksi ja
     koko ajatuskartta olisi sopinut kokonaan tulosteeseen.


> Date: Tue, 21 Feb 2012 15:05:46 +0200
> From: Toni Salminen <toni.a.j.salminen_at_student.jyu.fi>
> To: paatti_at_korppi.jyu.fi
> Subject: [paatti] Paatti-projektin vaatimusmäärittelyn hahmotelma
> 
> Hei,
> 
> Oheisista linkeistä löytyy huomisessa kokouksessa käsiteltävän
> vaatimusmäärittelyn hahmotelma.
> Hahmotelma on tehty freemind-ohjelmalla (http://freemind.sourceforge.net).
> Kaikissa linkeissä sisältö on sama, mutta esitystapa vaihtelee.
> 
> Freemind-ohjelmalla:
> http://sovellusprojektit.it.jyu.fi/paatti/dokumentit/vaatimusmaarittely/vaatimusmaarittelykartta_0.0.2.mm
> 
> Selaimella:
> http://sovellusprojektit.it.jyu.fi/paatti/dokumentit/vaatimusmaarittely/vaatimusmaarittelykartta_0.0.2.mm.html-
> tekstinä
> http://sovellusprojektit.it.jyu.fi/paatti/dokumentit/vaatimusmaarittely/vaatimusmaarittelykartta_0.0.2.jpeg-
> kuvana
> 
> 
> 
> Terveisin
> Toni Salminen
> projektipäällikkö

-- 
#  Jukka-Pekka Santanen (PhD, Mr)    #  santanen_at_mit.jyu.fi
#  Department of Mathematical        #  http://www.mit.jyu.fi/santanen/
#  Information Technology            #
#  University of Jyvaskyla           #  Room: Agora AgC418.2
#  P.O. Box 35 (Agora)               #  Phone: +358- (0)40 8053299
#  FIN-40014 University of Jyvaskyla #  
Received on 23.02.12 14:43:12

Tämän arkiston loi hypermail 2.2.0 : 23.02.12 14:43:13 EET