Olemme aiemmin keskustelleet vaatimussuunnittelun neljästä päätehtävästä.

Tarvesuunnittelu on prosessi, jossa kerätään ja määritellään, mitä palveluita järjestelmän tulisi tarjota.

Se keskittyy sen arviointiin, onko järjestelmästä hyötyä liiketoiminnalle (toteutettavuustutkimus), vaatimusten löytämiseen (selvittäminen ja analysointi), näiden vaatimusten muuntamiseen johonkin vakiomuotoon (määrittely) ja sen tarkistamiseen, että vaatimukset määrittelevät asiakkaan haluaman järjestelmän (validointi).

Käytännössä vaatimusmäärittely ei ole peräkkäinen prosessi, vaan se on iteratiivinen prosessi, jossa toiminnot lomittuvat toisiinsa.

Esimerkiksi iteroidaan ensin käyttäjävaatimukset; selvittäminen, spesifiointi ja validointi, ja toistetaan samat vaiheet järjestelmävaatimuksia varten.

Prosessin alkuvaiheessa suurin osa työstä käytetään korkean tason liiketoiminta- ja käyttäjävaatimusten ymmärtämiseen. Myöhemmin prosessissa enemmän ponnistuksia käytetään yksityiskohtaisten järjestelmävaatimusten selvittämiseen ja ymmärtämiseen.

Joidenkin mielestä vaatimussuunnittelu on prosessi, jossa sovelletaan strukturoitua analyysimenetelmää, kuten oliopohjaista analyysia. Tällöin järjestelmää analysoidaan ja kehitetään joukko graafisia järjestelmämalleja, kuten käyttötapausmalleja, jotka sitten toimivat järjestelmän määrittelynä.

Vaikka strukturoiduilla menetelmillä on oma roolinsa vaatimussuunnitteluprosessissa, vaatimussuunnittelussa on paljon muutakin kuin mitä nämä menetelmät kattavat.

Objektipainotteista analyysia ja suunnittelua käsitellään toisessa opetusohjelmasarjassa.

Käyttäjä- ja järjestelmävaatimukset

Tyypillisesti vaatimukset esitetään kahdella tarkkuustasolla; käyttäjä- ja järjestelmävaatimukset, joissa käyttäjä tarvitsee korkean tason lausumia vaatimuksista, kun taas järjestelmäkehittäjät tarvitsevat yksityiskohtaisemman järjestelmäeritelmän. Käyttäjä- ja järjestelmävaatimukset viittaavat siis vain eri yksityiskohtaisuustasoihin.

Erilaisten yksityiskohtaisuustasojen käyttäminen on hyödyllistä, koska se välittää tietoa kehitettävästä järjestelmästä erityyppisille lukijoille.

Loppukäyttäjät eivät siis välitä yksityiskohdista, vaan tarvitsevat yleisen, abstrahoidun kirjallisen vaatimuksen.

Kehitykseen osallistuvat ihmiset taas tarvitsevat sen, mitä heidän järjestelmänsä tarkalleen ottaen pitäisi tehdä.

Päädyt luultavasti moniin ongelmiin ja väärinkäsityksiin, jos et ole erottanut eri tason yksityiskohtia selkeästi toisistaan.

Käyttäjävaatimukset

Se kuvaa palvelut, joita järjestelmän pitäisi tarjota, ja rajoitteet, joiden puitteissa sen pitää toimia. Emme odota näkevämme mitään yksityiskohtaista tasoa tai sitä, mitä järjestelmä tarkalleen ottaen tekee, Se on enemmänkin yleisiä vaatimuksia.

Se kirjoitetaan yleensä luonnollisella kielellä ja toimitetaan kaavioilla.

Keskustelemme myöhemmin tässä sarjassa erilaisista tavoista määritellä vaatimukset.

Järjestelmavaatimukset

Järjestelmavaatimuksilla tarkoitetaan yksityiskohtaisempaa kuvausta järjestelmän palveluista ja toiminnallisista rajoitteista, kuten miten järjestelmää tullaan käyttämään, ja kehitysrajoitteista, kuten ohjelmointikielistä.

Tätä yksityiskohtaisuuden tasoa tarvitsevat järjestelmän kehittämiseen osallistuvat henkilöt, kuten insinöörit, järjestelmäarkkitehdit, testaajat jne.

Toiminnalliset & Ei-toiminnalliset vaatimukset

Ohjelmistovaatimukset jaetaan toiminnallisiin vaatimuksiin ja ei-toiminnallisiin vaatimuksiin.

Toiminnalliset vaatimukset

Se kattaa tärkeimmät toiminnot, jotka järjestelmän tulisi tarjota. Kun ne ilmaistaan käyttäjävaatimuksina, ne kuvataan yleensä abstraktisti.

Mutta tarkemmat toiminnalliset järjestelmävaatimukset kuvaavat järjestelmän toimintoja, sen syötteitä, käsittelyä; miten se reagoi tiettyyn syötteeseen ja mikä on odotettu tuotos.

Ei-toiminnalliset vaatimukset

Näissä rajoitetaan järjestelmän tarjoamia toimintoja.

Rajoitukset, kuten kuinka monta prosessia järjestelmä pystyy käsittelemään (suorituskyky), mitkä ovat ne (tietoturva)kysymykset, joista järjestelmän on huolehdittava, kuten SQL-injektiot …

Vikaantumisaste (luotettavuus), mitä kieliä ja työkaluja käytetään (kehitys), mitkä ovat ne säännöt, joita on noudatettava sen varmistamiseksi, että järjestelmä toimii organisaation lakien mukaisesti (lainsäädäntö).

Ei-toiminnalliset vaatimukset ovat usein kriittisempiä kuin yksittäiset toiminnalliset vaatimukset. Käyttäjät löytävät yleensä keinoja kiertää järjestelmän toiminto, joka ei oikeastaan vastaa heidän tarpeitaan. Epäonnistuminen ei-toiminnallisen vaatimuksen täyttämisessä voi kuitenkin merkitä sitä, että koko järjestelmä on käyttökelvoton.

Jos esimerkiksi lentokone ei meinaa täyttää luotettavuusvaatimuksiaan, se ei ole turvallinen käyttää, tai jos sulautettu ohjausjärjestelmä ei täytä suorituskykyvaatimuksiaan, ohjaustoiminnot eivät toimi oikein.

Ei-toiminnallisten vaatimusten tulisi olla mitattavissa

Aina kun mahdollista, ei-toiminnalliset vaatimukset tulisi kirjoittaa kvantitatiivisesti, jotta niitä voidaan testata. Niitä voidaan mitata, kun järjestelmää testataan, jotta voidaan tarkistaa, täyttääkö järjestelmä ei-toiminnalliset vaatimuksensa.

Käytännössä järjestelmän asiakkaiden on usein vaikea muuttaa tavoitteitaan mitattaviksi vaatimuksiksi. He eivät ymmärrä, mikä jokin numero määrittelee vaaditun nopeuden tai luotettavuuden. Joillekin tavoitteille, kuten ylläpidettävyydelle, ei ole olemassa mittareita, joita voitaisiin käyttää.

Mittauskelpoisten ei-toiminnallisten vaatimusten todentamisen kustannukset voivat olla hyvin korkeat, eivätkä asiakkaat välttämättä pidä näitä kustannuksia perusteltuina.

Ei-toiminnalliset ja toiminnalliset vaatimukset ovat riippuvaisia toisistaan

Ei-toiminnalliset vaatimukset ovat usein ristiriidassa keskenään, ovat vuorovaikutuksessa toisiinsa nähden, tai ne voivat jopa synnyttää toistensa kanssa muita toiminnallisia tai ei-toiminnallisia vaatimuksia.

Käyttäjävaatimus, joka liittyy turvallisuuteen, kuten käyttöoikeuden rajoittaminen valtuutetuille käyttäjille, voi tuottaa muita toiminnallisia vaatimuksia, kuten tarpeen sisällyttää järjestelmään käyttäjän todentamismahdollisuuksia.

Toiminnallisten ja ei-toiminnallisten vaatimusten erottaminen toisistaan

Käytännössä toiminnallisia ja ei-toiminnallisia vaatimuksia on vaikea erottaa toisistaan. Erottelu ei ole niin selkeä kuin niiden määritelmät antavat ymmärtää.

Toiminnallisten ja ei-toiminnallisten vaatimusten erottelu

Jos ei-toiminnalliset vaatimukset ilmoitetaan erillään toiminnallisista vaatimuksista, niiden välistä suhdetta voi olla vaikea ymmärtää.

Pitäisi kuitenkin nimenomaisesti tuoda esiin vaatimukset, jotka liittyvät selvästi järjestelmän emergentteihin ominaisuuksiin, kuten suorituskykyyn tai luotettavuuteen.

Emergentit ominaisuudet ovat pikemminkin järjestelmän ominaisuuksia kokonaisuutena kuin ominaisuuksia, jotka voidaan johtaa yksittäisten järjestelmäkomponenttien ominaisuuksien perusteella.