Ohjelmistotuotannon menetelmät Syksy 2003 Asiakasvaatimukset - Requirement engineering

1. Ohjelmistotuotannon menetelmätSyksy 2003Asiakasvaatimukset - Requirement engineering Päivi Ovaska Tutkijaopettaja LTY/Tite

2. Sisältö • Vaatimuksista tuotteeksi • Vaatimushallinta ongelmia • Vaatimus, esimerkkejä, tyyppejä, elinkaari • Vaatimustenhallinta, yleiskuva • Asiakasvaatimusten kartoittaminen • Kartoitusmenetelmiä • Asiakasvaatimusten analysointi • Vaatimuksia vaatimuksille • Vaatimusten verifionti, validointi ja jäljitettävyys • Vaatimusmuutosten hallinta, esimerkki • State of practice • Työkalutuki • Best practices • Avainkohdat • Hyviä tenttikysymyksiä • Mitä seuraavaksi …

3. Määrittely Suunnittelu& toteutus Vaatimuksista tuotteeksi asiakasvaatimukset ohjelmistovaatimukset

4. Vaatimushallinta ongelmia " The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult a establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No part of the work so cripples the resulting systems if done wrong. No other part is more difficult to rectify later" (Brooks, 1987)

5. Vaatimus (Requirement) • Stokes: “Collection of statements that describe in a clear, consistent and unambiguous manner all significant aspects of a proposed system”. • Karlsson: “current or future need that may be fulfilled”

6. Esimerkkejä vaatimuksista • “The user shall be given the following options...” • “The transmission speed shall be at least 1Mb´per second” • “The usability of the system is very important” • “If connection is lost, the previous saved status • shall be restored or the system restarted” • “The user interface shall be Windows 95 compatible”

7. Vaatimustyyppejä • Sommerwille, Southwell: • Functional requirements • how the system works, what it does • Nonfunctional requirements • Product requirements • e.g., performance, reliability, usability,portability • Process requirements • e.g., standards, programming languages • External requirements • e.g., interoperability, cost] • Asworth: • functions (“what”) • data (“what”) • nonfunctional requirements (“how well”) • goals (defined to guide the system developer in achieving the implementation of the agreed user requirements) • implementation/design constraints (e.g., use COBOL)

8. 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

9. Vaatimustenhallinta (Requirement engineering) • Ohjelmistokehityksen perimmäinen tavoite on päätyä asiakkaan tarpeet täyttävään ohjelmistoon • Vaatimustenhallinta koostuu niistä toimenpiteistä, jotka varmistavat edellä mainitun tavoitteen saavuttamisen • ottaen huomioon muutosten mahdollisuus (todennäköisyys) • sisältyy eri ohjelmistokehityksen vaiheisiin (tukitoimintoina eri vaiheissa muodostavat vaatimushallinnan kokonaisuuden)

10. … vaatimustenhallinta • paradoksi • vaatimuksiin kohdistuvia muutoksia on pyrittävä välttämään • kaikkia vaatimuksia ei voida tuntea ja ymmärtää etukäteen • vaatimusten jäädytys, hallittu vaatimusten muutosprosessi • ristiriitaiset vaatimukset • vaatimukset ovat olemassa • toteutus on kompromissi (valinta, priorisointi) • tuotteen kehittyminen elinkaaressa - jatkuva uusien vaatimusten keruu seuraavaa versiota varten • varautuminen myös tuleviin tarpeisiin tärkeää (ennakointi; vaikutukset arkkitehtuuriin ja toteutukseen) • vaatimukset -> järjestelmän ominaisuudet -> toteutetut piirteet (katkeamaton jäljitettävissä oleva ketju vaatimuksista järjestelmään)

11. … vaatimustenhallinta • Keskeisimmät vaatimustenhallinnan osa-alueet ovat – asiakasvaatimusten kartoittaminen – asiakasvaatimusten analysointi – vaatimusten jäljitettävyys asiakasvaatimusten käsittely – vaatimusmuutosten hallinta • vaatimusprosessin eteneminen seuraavassa kuvassa • katkeamaton vaatimusten ketju asiakasvaatimuksista toteutettuun järjestelmään • vaiheen päätteeksi on aina verifioitava että kaikki vaiheen syötteenä olevat vaatimukset on otettu huomioon asiakasvaatimusten synnyttäminen

12. Vaatimustenhallinta – Big Picture

13. Asiakasvaatimusten kartoittaminen Clients can only tell us what they want when they see it - Requirements gathering folklore • Ohjelmistot • markkinointi kerää, omassa organisaatiossa ideoidaan, asiakaspalaute, prototyypeistä saadut kokemukset, aivoriihityö, tutkimalla kilpailijoiden tuotteita, … • Räätälöidyt järjestelmät • Asiakasvaatimuksia kartoitetaan usein informaaleissa asiakasneuvotteluissa (”ME vastaan HE” mentaliteteetti) • Toiveiden erottaminen todellisista tarpeista

14. Osaamista eri osa-alueilta Vaatimusten kartoituksessa tarvitaan osaamista eri osa-alueilta Erillinen analyst –rooli, jolla osaamista näiltä alueilta

15. Esimerkki vaatimustenkeräysprosessista Business goals Organisational structure Stakeholder identification Stakeholder requirements Problem to be solved Application domain Goal prioritisation Domain requirements Domain knowledge filtering System constraints Existing systems Organisational requirements Asiakasvaatimukset

16. Monta näkökulmaa • riippumatta käytettävästä tavasta oleellista on kerätä (ja analysoida) vaatimuksia (viewpoint oriented elicitation) • monesta eri näkökulmasta • kaikilta intressiryhmiltä • ei ole olemassa yhtä oikeaa näkökulmaa vaatimusten perustaksi! • yksinkertainen esimerkki: pankkiautomaatti • intressiryhmiä • pankin asiakkaat • muut pankit • ohjelmisto ja HW-insinöörit • pankin markkinointi • pankin johto, virkailijat • tietokanta-administraattorit • tietoliikenne, tietoturva • henkilöstöhallinto • Vaatimukset kuvaat ”Mitä tehdään”” ei ”Miten tehdään?” • Käytännössä vaikea erottaa, toisen ihmisen miten on toiselle ihmiselle mitä

17. Kartoitusmenetelmiä • Haastattelut • Skenaariot • Soft system –menetelmät • Vaatimusten uudelleenkäyttö • Prototyyppien teko

18. Haastattelut • Vaatimusmäärittelijä tai analyst keskustelee tulevasta järjestelmästä eri intressiryhmien kanssa ja rakentaa siitä yhteisen ymmärryksen järjestelmästä • Suljettu haastattelu • vastauksia ennalta laadittuihin kysymyksiin • Avoin haastattelu • avoin keskustelu järjestelmän vaatimuksista • ei ennalta laadittuja kysymyksiä

19. Skenaariot • Skenaariot ovat esimerkkejä käyttäjän ja järjestelmän välisistä tyypillisistä keskusteluista • Loppukäyttäjät simuloivat järjestelmän käyttöä skenaarioiden avulla • Skenaariolla voidaan kuvata erilaisia esimerkkitilanteita, kun järjestelmää määritellään, ja näitä voidaan myöhemmin käyttää järjestelmän testitapauksina. (Oliopelissä käydään lävitse yhden skenaarion mukainen olioiden yhteistyönä toteutettu tehtävä.) • Skenaariota voidaan havainnollistaa esittämällä samat asiat graafisesti viestiyhteyskaaviossa

20. Esimerkki skenaariosta: maksuautomaatti • Esimerkki maksuautomaattiskenaariosta: • Asiakas antaa asiakastunnuksensa. • Maksutapahtuma pyytää maksajalta asiakkaan nimi- ja osoitetiedot. • Maksutapahtuma pyytää maksajan tiliä tarkistamaan tilinkäyttöoikeuden. • Tiedot näytetään asiakkaalle. • Asiakas syöttää maksun saajan tilinumeron. • Maksutapahtuma pyytää saajan tililtä saajan omistajatiedon (asiakastunnuksen). • Maksutapahtuma pyytää saajalta nimi- ja osoitetiedot. • Tiedot näytetään asiakkaalle. • Asiakas syöttää maksun määrän. • Maksutapahtuma välittää tiedot päiväkirjalle. • Päiväkirja pyytää maksajan tiliä tarkistamaan tilin katteen. Tieto, että tilillä on katetta, välitetään päiväkirjalle. • Päiväkirja pyytää saajan tiliä tekemään tilille pano -toiminnon ja tallettamaan maksutapahtuman tunnuksen tapahtumaluetteloonsa. • Päiväkirja pyytää maksajan tiliä tekemään tililtä otto -toiminnon ja tallettamaan maksutapahtuman tunnuksen tapahtumaluetteloonsa. • Tieto toiminnan onnistumisesta välitetään asiakkaalle

21. Soft system -menetelmät • SSM by Checkland • vähemmän määrämuotoinen malli järjestelmästä, joka ottaa huomioon sosiaaliset, poliittiset ja ihmimilliset tekijät, jotka mahdollisesti vaikuttavat järjestelmän ymmärtämiseen

22. SSM vaiheet

23. SSM vaiheiden kuvaus • Vaihe 1. Organisaation ihmisillä on ongelma, joka aiheuttaa vaatimusmäärittelyn käynnistymisen. Analyst (ulkopuolinen) kutsutaan apuun • Vaihe 2. Analyst kerää informaatiota (havainnoimalla, kyselemällä) ja antaa ongelman kuvauksen käyttäen erilaisia kuvaustapoja keskittyen: • organisaation rakenteeseen • järjestelmän tiedon käsittelyyn • sosiaalisiin seikkoihin organisaatiossa Kuvaukset ovat malleja siitä, kuinka järjestelmä nähdään, auttaa ongelman ratkaisijaa kiinnittämään huomiota ongelmatilanteeseen ja siinä vaikuttaviin sosiaalisiin ja inhimillisiin tekijöihin

24. … SSM vaiheiden kuvaus • Vaihe 3. Root definitions sisältävät yleensä 6 elementtiä, jossa määritellään: • Customer: everyone who stands to gain benefits from a system is considered as a customer of the system. • Actor: The actors perform the activities defined in the system. • Transformation process: The conversion of input to output. • Weltanschaung: (Our old friend). The “world view” must make the transformation process meaningful in context. • Owner: Who has the power to start up and shut down the system. • Environmental constraints: External elements outside the system exercising constraints. These include organizational policies as well as legal and ethical matters. • Vaihe 4. Konseptuaalisten mallien luominen • Vaihe 5. Vertaillaan konseptuaalista mallia todellisuuteen (Vaihe 4 vs. Vaihe 2) • Vaihe 6: Muutosten järkevyyden arvointi • Vaihe 7. Muutosten toteutus

25. Prototyyppaus • Vaatimusten keräyksessä ja validoinnissa • Throw-away prototype • Evolutionary prototype

26. Asiakasvaatimusten analysointi • selvitetään asiakasvaatimuksen todellinen tarve • arvioidaan sen tärkeys (prioriteetti) • ristiriitaisten vaatimusten sovittaminen yhteen • asiakasvaatimusten esittämismuodon ja perimmäisen syyn (miksi vaatimus on tärkeä) selvittäminen (asiakasvaatimus saattaa näkyä ohjelmistovaatimuksena) • priorisointiluokat: välttämätön, toivottu, valinnainen • myös tarpeen stabiilisuus, kiireellisyys, jne. vaikuttavat priorisointiin • vaatimusten muutosherkkyys (volatily), miten todennäköistä on, että vaatimus tulee tulevaisuudessa muuttumaan • voidaan arvioida projektin riskejä, auttaa valitsemaan sopiva elinkaarimalli ( vesiputous, vs. protoyypi) • vaikuttaa ohjelmistoarkkitehtuurin valintaan Asiakasvaatimus: Asiakkaan tarpeen tyydyttävä toiminnallisuus Ohjelmistovaatimus: Asiakasvaatimuksen toteutumisen ilmentymä ohjelmiston toiminnassa

27. Esimerkki Asiakasvaatimus:”Näytön alareunassa olevan stop-nappulan on vilkuttava punaisena, kun järjestelmän muistiresursseista on enää 10% vapaana” • Vaatimusta analysoitaessa (Miksi nappulan pitäisi tässä tilanteessa muuttua punaiseksi?) huomataan, että asiakkaan kokemuksen mukaan tässä tilanteessa on turvallisinta lopettaa järjestelmän käyttö, koska muistin loppuminen voi aiheuttaa ongelmatilanteen • Todellinen asiakasvaatimus: muistin loppumisesta aiheutuva ongelma on ratkaistava • Vaihtoehtoiset ratkaisutavat • punaisena vilkkuva stop-nappula lisätään järjestelmään • lisätään dialogi, joka varoittaa käyttäjää • ominaisuus lisätään siten, että käyttäjä voi räätälöidä varoituksen tyypin (dialogi tai punainen stop-nappula) ja varoituksen laukaisevan mustimäärän arvon esim. väliltä 5-20%

28. Vaatimuksia vaatimuksille • virheettömiä (correct) • asiakkaan käsityksen mukaisia • todentaminen vaikeaa • ristiriidattomia (consistent) • realistisia (realistic) • toteutuskelpoisuus suhteessa järjestelmän ympäristön ja sidosryhmien asettamiin rajoitteisiin ja mm.suorityskykyyn • tarpeellisia (needed) • priorisointi, luokittelu • todellinen tarve ei usein käy ilmi asiakaan haastatteluista • sovellusaluetuntemus avainasemassa

29. Vaatimuksia vaatimuksille • todennettavissa (verifiable) • vaatimuksen toteutuminen tuotteessa tulee olla todennettavissa • toiminnallisten vaatimusten osalta voidaan joka vaiheen tuloksesta osoittaa ne kohdat jotka toteuttavat tietyn vaatimuksen • ei-toiminnalliset ominaisuudet (sekä rajoitteet) ovat joskus konkreettisesti mitattavissa (esim. suorituskyky) • jäljitettävissä (traceable) • eteenpäin jäljitettävyys: asiakasvaatimus voidaan jäljittäätoteutukseen saakka • taaksepäin jäljitettävyys: koodimodulit voidaan jäljittää asiakasvaatimuksiin asti • ei-toiminnalliset vaatimukset ja rajoitteet eivät yleensä ole jäljitettäviä, ominaisuus hajoaa kaikkialle toteutukseen

30. Vaatimusten verifiointi ja validointi • asiakasvaatimukset luovat pohjan kehitystyölle • asiakasvaatimus voi kuvautua määrittelyyn moneksi toiminnoksi • yksi toiminto (määrittelyssä) voi perustua moneen asiakasvaatimukseen • verifiointi (todennus): kussakin vaiheessa tarkastetaan vaatimusten toteutuminen vertaamalla tulosdokumenttia syötedokumentteihin • dokumentoitu verifiointiin perustuva ketju asiakasvaatimuksista toteutettuun toimintoon mahdollistaa jäljitettävyyden • validointi (kelpoistaminen) • tutkitaan että järjestelmä vastaa asiakkana tarpeita • validointi = todellisten asiakastarpeiden ja sovittujen (toteutettujen) asiakastarpeiden välinen verifiointi • käyttäjätestit (useita erilaisia käytäntöjä)

31. Vaatimusten jäljitettävyys • jäljitettävyystyypit • toimintojäljitettävyys (design traceability) • elinkaaren vaiheiden välillä • alkuperäjäljitettävyys (source traceability) • jokaisella vaatimuksella ”vastuuhenkilö” asiakkaan organisaatiossa, joten vaatimukset voidaan jäljittä alkuun saakka • vaatimustenvälinen jäljitettävyys (requirements traceability) • vaatimus edellyttää toisen vaatimuksen olemassaoloa jotta se voi toteutua • menettelytapoja jäljitettävyyden aikaansaamiseksi • hyvä laatujärjestelmän mukainen dokumentaatio • jäljitettävyysmatriisi: kuvaa riippuvuuksia siakasvaatimus/toiminto vaatimus/vaatimuksen asettaja vaatimus/vaatimus • työkalut, esim. RationalRequisite

32. Esimerkki jäljitettävyysmatriisista Requisite Pro -työkalussa

33. Vaatimusmuutosten hallinta • vaatimustenhallinta pitää suunnitella • miten tunnistetaan • miten yksilöidään • muutostenhallinta (tarvitaan selkeät säännöt) • miten muutokset hyväksytään • miten muutosten kerrannaisvaikutukset hoidetaan (jäljitettävyys) • yksinkertainen muutosprosessi

34. Esimerkki yksinkertaisesta muutosprosessista

35. State-of-Practice • Vain muutamat organisaatiot käyttävät systemaattista menetelmää tai apuvälineitä • Vaatimusten analysointi ja perimmäisen syyn selvittäminen jätetään usein tekemättä (vaatimukset kerätään sellaisenaan, kaikki vaatimukset yhtä tärkeitä) • Vaatimusten jäljitettävyys harvoin toteutuu • Muutokset vaatimuksissa ovat harvoin hallittuja ja harvoin päivitetään dokumentteihin

36. Työkalutuki • Useita työkaluja vaatimusten hallintaan • Esim. Doors, Rational Requisite Pro (tällä opintojaksolla)

37. Best Practices (Hofmann&Lehner 2001) in requirements engineering • Käyttäjien osallistuminen • Tunnista ja tutki kaikki mahdolliset vaatimuslähteet • Parhaat/kokeneimmat henkilöt vaatimusmäärittelyyn • 15-30% koko projektin kustannuksista • Hyvät dokumenttipohjat • Tunnista sidosryhmät ja keskustele kaikkien kanssa • Priorisoi vaatimukset • Käytä malleja ja prototyyppejä • Säilytä vaatimusten jäljitettävyys • Katselmoi ja tarkasta

38. Avainkohdat • Vaatimustenhallintaan kuuluu vaatimusten kartoitus, analysointi, sekä vaatimusten muutoksenhallinta • Vaatimusten analysointi on iteratiivista toimintaa johon kuuluu • luokittelu, priorisointi, ristiriitojen selvitys, validointi • Systeemeillä on monia intressiryhmiä joilla on erilaiset vaatimukset • Sosiaalisia ja organisatorisia seikkoja systeemin vaatimuksissa ei voi sivuuttaa – tyypillisiä ristiriitaisten vaatimusten lähteitä • Vaatimusten analysoinnissa ja täsmentämisessä tarkistetaan validius, ristiriidattomuus, täydellisyys, realismi ja todennettavuus • Asiakasvaatimuksiin tulee muutoksia viimeistään ylläpidon aikana, tavallisesti jo kehitysprosessin kuluessa

39. Avainkohdat • Syitä asiakasvaatimusten muutoksiin • väärin ymmärretyt vaatimukset • unohdetut vaatimukset • vääräksi tai turhiksi osottautuvat vaatimukset • projektin viivästyessä tehty vaatimusten priorisointi • markkinatilanteen nopea muuttuminen • epäonnistuneet teknologiavalinnat • Vaatimustenhallinta kokonaisuudessaan on tukitoiminto joka pitää suunnitella hyvin ja noudattaa kurinalaisesti • Vaatimustenhallintaan tarjolla useita työkaluja

40. Hyviä tenttikysymyksiä • Millaista osaamista tarvitaan vaatimusten keräyksessä? • Mitä tarkoitetaan eteen- ja taaksepäin jäljitettävyydellä ohjelmiston kehitystyössä? Miten nämä jäjitettävyyden muodot toteutuvat • Vaatimusten analysointi osana vaatimusten hallintaa • Mitä tarkoitetaan verifioinnilla ja validoinnilla vaatimushallinnan yhteydessä? • Kuvaile, minkälainen voisi olla hallittu vaatimusten muutosprosessi. Miten se tukee jäljitettävyyttä? • Miten vaatimus muuttuu ohjelmistokehityksen elinkaaren aikana? Pohdi tämän merkitystä koko ohjelmistokehitykseen • Miksi sosiaalisia, organisatoorisia ja inhimillisiä tekijöitä ei pidä sivuuttaa vaatimusten kartoituksessa ja analysoinnissa?

41. Mitä seuraavaksi …

42. Harjoitukset ja harjoitustyö • Tehdään Konepaja Oy:n palkanlaskentajärjestelmälle asiakasvaatimusten kartoitus ja analysointi • Tutustutaan Requisite Pro -ohjelmistoon • todetaan harjoitustyön rajoitteet

43. Asiakasvaatimusten mallinnus: Asiakasvaatimuksista ohjelmistovaatimuksiksi • Syitä • selventäminen • ymmärtäminen • arviointi • todentaminen • analysointi • Kohteita • prosessi, rakenne, roolit ja vastuut, tietovuo, vuorovaikutukset, ... • staattiset / dynaamiset piirteet • yleinen / yhtä erikoistapausta kuvaava

44. Asiakasvaatimusten mallinnus • Mallintamisen tekniikoita: • teksti, grafiikka, animointi, prototyyppi, ... • luonnollinen kieli tai formaali notaatio • Toiminnallisten vaatimusten mallintaminen, esim: • rakenteinen analyysi (SADT, SSADM, JSD) • oliosuuntautunut analyysi (OOA, OOSE, OMT, UML) • formaalit menetelmät (SCR, RSML, Z, VDM) • Usein tarvitaan joukko erilaisia malleja eri asioista. UML (Unified Modeling Language) on mallinnuskieli, joka tukee koko elinkaarta ja jolle on olemassa eri toimittajien valmistamia välineitä. Ne sisältävät erilaisia kaaviotyyppejä, kuten käyttötapauskaavio, luokkakaavio, oliokaavio, komponenttikaavio, sijoittelukaavio, sekvenssikaavio, yhteistyökaavio, tilakaavio ja toimintokaavio. • Asiakasvaatimusten mallinnuksesta ja UML kielestä seuraavilla luennoilla