Re: Paatti-projektin vaatimusmäärittelyn hahmotelma

Kirjoittajan mukaan: Toni Salminen <toni.a.j.salminen_at_student.jyu.fi_at_localhost>
Päiväyksen mukaan: Mon, 27 Feb 2012 18:03:43 +0200
Hei,

Ryhmämme kävi tänään Santasen viestin huomioita läpi ja totesimme, että
emme vastaa viestin jokaiseen kysymykseen erikseen, vaan tarkistamme ja
korjaamme vaatimusmäärittelyämme ehdotuksien pohjalta tämän viikon
aikana.

Tällä viikolla yritämme käyttöliittymäsuunnittelun avulla selkeyttää
tutkijan puolta ohjelmistosta. Esimerkiksi sitä, miten ryhmien
hallinta, tapahtumien aikataulutukset ja tapahtumien luonti toimisivat
käytännössä.

Toni Salminen
projektipäällikkö

Thu, 23 Feb 2012 14:43:12 +0200
Jukka-Pekka Santanen <jukka-pekka.santanen_at_mit.jyu.fi> kirjoitti:

> 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ö
> 
Received on 27.02.12 18:03:43

Tämän arkiston loi hypermail 2.2.0 : 27.02.12 18:03:55 EET