ohjelmistotuotannon menetelmät syksy 2003 asiakasvaatimukset - requirement engineering

Ohjelmistotuotannon menetelmätSyksy 2003

Asiakasvaatimukset - Requirement engineering

Päivi Ovaska

Tutkijaopettaja

LTY/Tite

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 …

Vaatimuksista tuotteeksi

MäärittelySuunnittelu&toteutus

ohjelmistovaatimukset

asiakasvaatimukset

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)

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”

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”

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)

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

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)

… 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)

… 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

Vaatimustenhallinta – Big Picture

Asiakasvaatimusten kartoittaminen

• 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

Clients can only tell us what they want when they see it- Requirements gathering folklore

Osaamista eri osa-alueilta

Application Problem to domain be solved Stakeholder Business needs and context constraints

Vaatimusten kartoituksessa tarvitaan osaamista eri osa-alueilta

Erillinen analyst –rooli, jolla osaamista näiltä alueilta

Esimerkki vaatimustenkeräysprosessista

Problem to be solved

Businessgoals

Systemconstraints

Domainknowledgefiltering

Goalprioritisation

Stakeholderidentification

Organisationalrequirements

Domainrequirements

Stakeholderrequirements

Existingsystems

Applicationdomain

Organisationalstructure

Asiakasvaatimukset

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ä

Kartoitusmenetelmiä

• Haastattelut

• Skenaariot

• Soft system –menetelmät

• Vaatimusten uudelleenkäyttö

• Prototyyppien teko

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ä

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

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

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

SSM vaiheet

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 organisaatiossaKuvaukset 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

… 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

Prototyyppaus

• Vaatimusten keräyksessä ja validoinnissa

• Throw-away prototype

• Evolutionary prototype

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

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%

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

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

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ä)

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 riippuvuuksiasiakasvaatimus/toiminto vaatimus/vaatimuksen asettajavaatimus/vaatimus

• työkalut, esim. RationalRequisite

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

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

Esimerkki yksinkertaisesta muutosprosessista

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

Työkalutuki

• Useita työkaluja vaatimusten hallintaan

• Esim. Doors, Rational Requisite Pro (tällä opintojaksolla)

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

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

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

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?

Mitä seuraavaksi …

Harjoitukset ja harjoitustyö

• Tehdään Konepaja Oy:n palkanlaskentajärjestelmälle asiakasvaatimusten kartoitus ja analysointi

• Tutustutaan Requisite Pro -ohjelmistoon

• todetaan harjoitustyön rajoitteet

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

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