Vaatimusten keräys ja hallinta Inka Vilpola 19.4.2006 Sisältö Vaihe ISO 13407 -prosessissa Vaatimusten lajit (teoria) Vaatimukset hyvälle vaatimukselle Vaatimusten hallinta Vaatimusten kerääminen Vaatimusten keräysmenetelmiä - Olemassa olevan järjestelmän arviointi - Käyttöskenaario - Use case - Focus Groups - Tehtäväanalyysi Vaatimusten luokittelu (käytäntö) Vaatimusten analysointi ja mallintaminen Vaatimusten priorisointi Vaatimukset tavoitteiksi
Vaihe ISO 13407 -prosessissa Vaatimusten lajit Vaatimustyypit: - Käyttäjän vaatimukset (user requirements) - Järjestelmävaatimukset (system requirements) - Ohjelmiston määrittelykuvaukset (software design specification) Vaatimusluokat - Toiminnalliset vaatimukset (functiona) - Ei-toiminnalliset vaatimukset (non-functional)
Vaatimukset hyvälle vaatimukselle Virheettömyys Ristiriidattomuus Täydellisyys Realistisuus Tarpeellisuus Todennettavuus Jäljitettävyys Tasapaino ymmärrettävyyden ja epäselvyyden välillä Ymmärrettävyys (understadability) Sweet spot Monimerkityksellisyys (ambiquity)
Esimerkkivaatimus Sovelluksen tulee olla helppokäyttöinen - > Tarkoittaako tämä, että a. Käyttäjä saavuttaa helposti ja tehokkaasti tavoitteensa b. Sovelluksessa ei ole yli viittä toimintoa c. Sovelluksessa on vain yksi painike d. Sovelluksen käyttöliittymässä on paljon kivoja värejä e. Käyttäjäryhmään B kuuluvalta käyttäjältä menee tehtävän S suorittamiseen alle 4 minuuttia f. Käyttäjäryhmän C kuuluva käyttäjä muistaa 3 viikon kuluttua edellisestä käytöstä, kuinka toiminto T suoritetaan Kuinka välttää epäselvyydet Yritä muistaa käyttäjävaatimukset ulkoa (memorization heuristic) Etsi avainsanojen merkitykset (keyword technique) Lue vaatimukset ääneen ja painota yksittäisiä sanoja tulkiten niitä eri tavoin (emphasis technique) Käytä kuvia, piirroksia tai formaaleja kuvaustekniikoita (Petja)
Vaatimusten elinkaari Asiakastarve ( raaka vaatimus ) Analysoitu ja ymmärretty vaatimus ( puhdistettu vaatimus ) Järjestelmään ehdotettu vaatimus (ominaisuus ehdokas) Valittu vaatimus (hyväksytty vaatimus, järjestelmän ominaisuus) Toteutettavissa oleva vaatimus (tekninen vaatimus) Toteutettu vaatimus (toteutus olemassa) Testattu vaatimus http://www.it.lut.fi/kurssit/05-06/ti5214100/luennot/2_luento.ppt Esimerkki RDEM-elinkaarimalli RDEM-malli (Requirement Driven Evolution Model) Markus Miettinen, Vaatimustenhallinta ohjelmistotuotannossa [1] P. Carlshamre and B. Regnell. Requirements lifecycle and release planning in market-driven requirements eng processes. In Proc. 11th International Workshop on Data Expert Systems Applications, pages 961 965, Sept. 200
Vaatimusten hallinta Vaatimusmäärittelyssä huomioitava: - Usean henkilön samanaikaisesti suorittama ylläpito - Erilaiset näkymät eri osapuolille - Vaatimusten taustatiedot - Kaksoiskappaleiden ja ristiriitojen löytäminen - Käyttökelpoisuus suunnitteluvaiheessa - Hyväksymistestaus Vaatimusmäärittely on asetettava versiohallinnan alaisuuteen Vaatimusmäärittelyn jäljitettävyyteen on kiinnitettävä erityistä huomiota Välineitä vaatimusten hallintaan - Pienten järjestelmien vaatimusten hallinta voidaan toteuttaa yleiskäyttöisillä välineillä (tekstinkäsittely, taulukkolaskenta, tietokanta). - Erityisvälineet (CORE, DOORS, RequisitePro,...) Vaatimusten kerääminen Lähtökohtana voi olla - uuden tuotteen suunnittelu (greenfield engineering) - uudelleensuunnittelu (reengineering) - järjestelmän uudelleenkäyttö uudella rajapinnalla (interface engineering) Käytettävyysmenetelmien avulla kerätään tietoa käyttöliittymästä, käyttäjistä, heidän tehtävistään ja käyttöympäristöstä
Vaatimusten keräysmenetelmiä Olemassa olevan tuotteen arviointi Käyttöskenaario Käyttötapaus Focus Groups Tehtäväanalyysi Olemassa olevan tuotteen arviointi Käytettävyysongelmien tunnistaminen Käytettävyyden lähtötason määritys mittaamista varten Tee näin: 1. Tutki ja analysoi käyttökonteksti 2. Valitse tärkeimmät tehtävät 3. Valitse tärkeimmät käyttäjäryhmät 4. Suorita käytettävyystestaus 5. Luokittele ilmenneet ongelmat Lista käytettävyysongelmista luokiteltuna vakavuuden perusteella Käytettävyysongelmien priorisointi tuotekehitystiimin kesken Mittarit tuotteen käytettävyystavoitteille
Käyttöskenaario Kuvaa kuinka käyttäjä suorittaa tehtävän tietyssä käyttöympäristössä Käyttäjä- ja tehtäväorientoinut käyttöskenaario Hyvä käyttöskenaario kattaa myös ongelma- ja erikoistilanteet Tee näin: 1. Kokoa yhteen tuotekehitykseen ja tuotteenkäyttäjiin kuuluvia henkilöitä 2. Määrittele kohdekäyttäjäryhmä, tehtävät ja käyttökonteksti 3. Määrittele käyttäjän tavoitteet tehtävän suorittamiseksi 4. Määrittele jako käyttäjän ja järjestelmän suorittamisen toimintojen välillä 5. Luetteloi käyttäjän tehtävät, tavoitteet ja motivaatiot suunniteltavan järjestelmän käytölle Arvio tehtävien suorittamiseen tarvittavasta ajasta Arvio tehtävien suorittamiskriteereistä Pohja käytettävyystavoitteille Pohja käyttäjäkeskeisen arvioinnin tehtäville Arvio järjestelmän käyttäytymisestä ongelmatilanteissa Käyttötapaus (Use case) Käyttötapaus on skenaarion abstraktio Ylätason käyttäjäkeskeinen kuvaus järjestelmän käytöstä Kuvaa MITÄ järjestelmällä on tarkoitus tehdä (ei MITEN) Rajaa kehitettävän kohteen Ei sido toteutusta Tee näin: 1. Määrittele primäärikäyttäjät = actor 2. Määrittele mitä actor haluaa tehdä järjestelmällä, jokaisesta tehtävästä tulee yksi käyttötapaus 3. Määrittele jokaisesta käyttötapauksesta kuinka tehtävä normaalisti etenee (basic course) 4. Laajenna käyttötapauksia kuvaamalla muut samanaikaiset tapahtumat tai vaihtoehdot 5. Vertaile käyttötapauksia keskenään ja yhdistä samankaltaisuudet Arvio tuotteen sisältämästä toiminnallisuudesta Arvio vaadituista ominaisuuksista
Focus Groups Ryhmäkeskustelu mielipiteistä, asenteista kehitysideoista Ei suositella varsinaiseen arviointiin Tee näin: 1. Suunnittelu keskustelun käsikirjoitus ylätasolla 2. Kokoa 6-12 riittävä erilaista henkilöä, mahdollisesti toisilleen entuudestaan tuntemattomia ihmisiä. Kerro kutsussa tilaisuuden tarkoitus 3. Valmistele stimulus-materiaali herättämään keskustelua 4. Kokenut moderaattori ohjaa keskustelua ja pitää sen tasapuolisena 5. Osallistujia kiitetään Hypoteesi pohjaksi kvalitatiiviselle tai kvantitatiiviselle jatkotutkimukselle Jatkokehitysideoita Tehtäväanalyysi (task analysis) Kuvaus käyttäjän toimenpiteistä järjestelmää käyttäessä, kun hän suorittaa tehtävän Tarkoitus selvittää järjestelmän toimintaa ja sen tietovirrat Toimii pohjana uuden järjestelmän toimintoja ja tietovirtoja suunniteltaessa Tee näin: 1. Valitse analysoitava tehtävä ja jaa se 4-8- alatehtävään (subtask) 2. Kuvaa alitehtävät kerrosdiagrammilla varmistaaksesi, että ne muodostavat yhdessä kokonaisuuden ilman katkoksia 3. Päätä kuinka pitkälle alatehtävät jaetaan edelleen 4. Käy kaikki alatehtävät läpi johdonmukaisesti samalla tarkkuudella 5. Esitä kuvatut alatehtävät jollekin, joka ei ole ollut mukana pilkkomisessa, mutta tuntee analysoitavan tehtävän, varmistuaksesi, ettei tehtävässä ole katkoksia. Yksityiskohtainen kuvaus käyttäjän ja järjestelmän välisestä vuorovaikutuksesta tehtävän aikana Kuvia käyttöliittymästä liittyen ongelmakohtiin Paljastaa tehtäväprosessin ongelmat, käyttäjien erot ja epäjohdonmukaisuudet tehtävien välillä
Vaatimusten luokittelu FURPS+ (Jacobson, 1999) on eräs vaatimusten luokittelu. Functionality (toiminnalliset vaatimukset) Usability Reliability Performance Supportability + = rajoitteita joidenkin muiden asioiden suhteen: suunnittelu (design), toteutus (implementation), rajapinnat (interface), fyysiset ominaisuudet (physical), paketointi (packaging), toiminta (operation), laillisuuskysymykset (legal) http://staff.cs.utu.fi/kurssit/ohjelmistotuotanto/06/vaatimukset.pdf Vaatimusten analysointi ja mallintaminen Mallintamisen syitä: - Selventäminen, ymmärtäminen, arviointi, todentaminen, analysointi Mallintamisen kohteita: - prosessi, rakenne, roolit ja vastuut, tietovuo, vuorovaikutukset,... Mallintamisen tekniikoita: - teksti, grafiikka, animointi, prototyyppi,... Mallinnuksen ominaisuuksia - Staattiset / dynaamiset piirteet - Yleinen / yhtä erikoistapausta kuvaava - Luonnollinen kieli tai formaali notaatio - Mallinnus voi olla toimintokeskeinen, tietokeskeinen tai oliokeskeinen Ei-toiminnallisten vaatimusten mallintaminen, esim: - laatukysymykset (QFD, win-win) - suorituskyky (ajastetut Petri-verkot) - Luotettavuus (probabilistinen MTTF) Usein tarvitaan joukko erilaisia malleja eri asioista
UML-mallinnus UML (Unified Modeling Language) - Tukeekokoelinkaarta - Eri toimittajien valmistamia välineitä - Erilaisia kaaviotyyppejä, kuten käyttötapauskaavio, luokkakaavio, oliokaavio, komponenttikaavio, sijoittelukaavio, sekvenssikaavio, yhteistyökaavio, tilakaavio ja toimintokaavio - Visuaalinen kehityskieli - Yleispätevä eri sovellusalueille Esimerkki vuorovaikutuskaavio Lisää esimerkkejä: http://www.visualcase.com/diagrams.htm
Vaatimusten priorisointi Priorisointiperusteita - Kiireellisyys, ydintoiminnallisuus, muutosherkkyys, poliittiset syyt Priorisointimenetelmiä: - Luokittelu - Järjestäminen - Priorisointiasteikko 1-10 esim. hyöty ja kustannus Tärkeät priorisoinnin jälkeen luokittelu: Helpot - Pareittain vertailu Vaikeat - Kiinteä summa Turhat Vaatimusmäärittelyn tulokset Tuotteen käytettävyystavoitteet Tuotteen toiminnallisten ja eitoiminnallisten vaatimusten kuvaus Vaatimusten priorisointi Vaatimusten kuvaus mallintamalla - soveltuu suunnittelun pohjaksi Vaatimuksia vastaavat testitapaukset