Tehtävänanto (lyhennetty): Olet mukana menestyvässä ohjelmistotalossa nimeltä GuruSoft ja olette kehittäneet menestyvän ohjelmiston, KillerApp, joka on myynyt jo 10 000 kopiota. Asiakkailta tulee paljon palautetta ja sinulla on useita ideoita, mitä sisällyttää ohjelmiston seuraavaan versioon. Kirjoita ehdotus, kuinka toteuttaisit vaatimusten määrittelyn yrityksessäsi. Essee arvosteltiin asteikolla 0-10 p. Essee oli osa Teknillisen korkeakoulun kurssin T-76.3601 Ohjelmistotuotannon perusteet suorittamista.

Essee 1 - Vaatimusten määrittely (Requirements engineering)

Noudattaen Pressmanin kirjassaan Software Engineering esittämää lähestymistapaa, vaatimusten määrittelyn ensimmäisessä vaiheessa tarkastellaan, ketkä käyttävät tuotetta ja näin tunnistetaan kaikki tuotteen sidosryhmät. Osa voi olla jo hyvin tunnettuja, koska tuotteen nykyinen versio on jo ollut laajassa käytössä, mutta tuotteen käytön aikana on voinut ilmetä uusia merkittäviä sidosryhmiä, joiden toivomukset pitää myös ottaa huomioon.

Kun eri käyttäjäryhmät on tunnistettu, kerätään tietoa käyttäjien tarpeista (miten käyttäjät käyttäjät tuotetta nyt, mitä parannuksia he toivovat jne.). Tarpeista tehdään vaatimuksia (mitä tuotteen pitäisi voida tehdä, jotta se tyydyttää tarpeen). Vaatimuksia voidaan kerätä esim. käyttäjäpalautteesta, jota on saatu tuotteen nykyisen version käyttäjiltä tai haastattelemalla tuotteen käyttäjiä. Myös muiden kuin loppukäyttäjien vaatimuksia kerätään, mm. ylläpitäjiltä ja suunnittelijoilta. Myös kilpailevia tuotteita on hyvä tarkkailla, joista voi saada hyviä uusia ideoita.

Kerätyt vaatimukset jaotellaan kolmeen eri kategoriaan: liiketoiminnalliset vaatimukset, käyttäjävaatimukset ja tekniset vaatimukset. Lisäksi nämä jaotellaan vielä kahteen eri kategoriaan: funktionaaliset vaatimukset ja ei-funktionaaliset vaatimukset. Funktionaaliset vaatimukset kuvaavat järjestelmän toimintoja tai sitä, mitä järjestelmän pitää tehdä käyttäjän näkökulmasta. Ei-funktionaaliset vaatimukset kuvaavat järjestelmän ominaisuuksia kuten tehokkuus ja luotettavuus sekä rajoituksia kuten standardit tai laitteiston asettamat vaatimukset. Jako näihin osiin auttaa tuotteen suunnittelemisessa jatkossa (mm. käyttöliittymien ja arkkitehtuurin suunnittelussa).

Seuraavaksi priorisoidaan kerätyt vaatimukset keskustelemalla käyttäjien kanssa vaatimusten tärkeydestä. Käyttäjiltä kysytään, miten tärkeinä he pitävät vaatimuksia ja tämän perusteella vaatimuksia yhdistellään, karsitaan tai muutetaan ja asetetaan ne tärkeysjärjestykseen. Tässä voidaan käyttää useita menetelmiä kuten kirjassa Designing Interactive Systems esitettyä ns. MoSCoW-sääntöä, jossa vaatimukset jaetaan neljään eri ryhmään:

1. Pakko olla (Must have)
2. Pitäisi olla (Should have)
3. Voisi olla (Could have)
4. Haluttaisiin (Want to have)

Ensimmäisen ryhmän vaatimukset toteutetaan ensin. Niiden tärkeys on kaikista suurin. Jos niitä ei pystytä toteuttamaan, ovat käyttäjät todennäköisesti tyytymättömiä uuteen versioon tuotteesta, koska siinä ei ollut heidän eniten toivomiaan uudistuksia. Jos aikaa jää, toteutetaan myös toisen ja kolmannen ryhmän vaatimukset kyseisessä tärkeysjärjestyksessä. Neljännen ryhmän vaatimuksia ei toteuteta tällä kertaa, mutta ne voidaan toteuttaa ehkä myöhemmissä projekteissa.

Kun vaatimukset on kerätty ja priorisoitu, esitetään ne sopivassa muodossa käyttäen apuna esim. use-case -diagrammeja ja skenaarioita. Näiden esitysten avulla voidaan arvioida vaatimuksia käyttäjien kanssa. Tärkeää on, että suunnittelijat ovat ymmärtäneet käyttäjien vaatimukset oikein ja, että vaatimukset ovat selkeitä sekä yksikäsitteisiä eivätkä vaatimukset ole ristiriidassa tai mitään hyvin tärkeää ei puutu. Tässä vaiheessa etsitäänkin käyttäjien hyväksyntää vaatimuksille ja saadaan vahvistus sille, että vaatimus on oikein ymmärretty. Arviointi toteutetaan keskustellen vaatimuksista pienissä ryhmissä, jotka koostuvat suunnittelijoista, käyttäjistä ja muista sidosryhmistä.

Hyväksytyistä vaatimuksista tehdään taulukko, josta nähdään, mikä vaatimus vastaa mitäkin tuotteen ominaisuutta, eli mikä tuotteen ominaisuus toteuttaa minkäkin vaatimuksen. Tämä helpottaa vaatimusten toteuttamisen valvomista ja mahdollisten muutosten tekemistä vaatimuksiin. Taulukosta näkee helposti, mitkä vaatimukset on jo toteutettu ja mihin osiin tuotetta vaatimuksen muuttaminen vaikuttaa. Lopuksi vaatimukset järjestetään niiden tärkeysjärjestyksen perusteella "paketteihin", jotka on tarkoitus toteuttaa samassa lisäyksessä (increment). Näin voidaan alkaa suunnittelemaan näitä uusia ominaisuuksia ja lopulta päästä toteuttamaan niitä.

Lähteet:

• Pressman. 2005. Software Engineering: A Practitioner's Approach, 6th edition. McGraw-Hill. 912 s. ISBN 007-123840-9.
• Benyon, D., Turner, P. & Turner, S. 2005. Designing Interactive Systems - People, Activities, Contexts, Technologies. Harlow, Englanti: Addison Wesley. 729 s. ISBN 0-321-11629-1.