Vaatimusmäärittelystä puhuttaessa ensimmäisenä mieleen tulee pitkä vaatimusluettelo, jota ylläpidetään joko excelissä tai jossain vaatimushallintavälineessä. Kukin vaatimus pyritään kirjoittamaan itsenäiseksi ja yksikäsitteiseksi. Vaatimus kohdistuu useimmiten toteutettavaan tietojärjestelmään, mutta voi koskea myös toimintatapaa tai jotain muuta.
Vaatimuksia voi kirjoittaa monesta eri näkökulmasta, karkeammalla tai tarkemmalla tasolla. Aivan ylätason vaatimuksia, jotka on tunnistettu ideointivaiheessa, kutsutaan joskus ”toiveiden tynnyriksi”. Silloin vaatimukset voivat olla epäformaalejakin ja ne tarkentuvat työn edetessä. Kyse on siis varsin monimuotoisesta asiasta, joka elää tilanteen mukaan.
Entä kirjoitetaanko kaikki asiat vaatimuksen muotoon? Moni muukin asia käyttäytyy vaatimuksen tavoin, kun tarvetta aletaan kuvata. Tarpeen voi kuvata myös prosesseina, arkkitehtuurikuvina tai muina malleina. Kirjoitetaanko silloin yhdeksi vaatimukseksi “Järjestelmän on noudatettava arkkitehtuuria” vai puretaanko arkkitehtuuri niin moneksi vaatimukseksi, että kaikki tarvittava on sanottu myös vaatimuksina? Saman asian kuvaaminen usealla eri tavalla on päällekkäistä työtä. Se on turhaa työtä, joka aiheuttaa myös ylläpito-ongelman. Jos muutoksia tulee, on se muistettava tehdä moneen paikkaan. Jos tehtyä lopputulosta verrataan nimenomaan vaatimuksiin (eli tarkastetaan vaatimus vaatimukselta, toteutuvatko ne), voi olla viisainta kirjoittaa kaikki myös vaatimuksina, vaikka se muuten turhalta tuntuukin.
Vaatimuksilla on hinta eli se, mitä vaatimuksen toteuttaminen maksaa. Tästä syystä vaatimusten priorisointi on tärkeää ja usein nimenomaan toiminnallisten vaatimusten tarpeellisuutta arvioidaan. Tarvitseeko käyttäjä todellakin tämän toiminnallisuuden vai pärjättäisiinkö ilman? Ei-toiminnallisiin vaatimuksiin ei kiinnitetä ollenkaan niin paljoa huomiota, vaikka niiden kustannusvaikutus voi olla erittäin suuri. Jos halutaan korkea tietoturva ja samaan aikaan huikea suorituskyky, niin kannattaa varautua laittamaan hankintaan aivan eri määrä rahaa kuin vähäisemmillä vaatimuksilla. Entäpä vaatimukset käytännön järjestelyille? Onko help deskiä päivystettävä kellon ympäri useamman ihmisen voimin, jotta puhelimeen voidaan vastata välittömästi? Kaikki tämä onnistuu, mutta maksaa lisää.
Valmisohjelmistot tuovat oman värinsä vaatimusmäärittelyyn. Silloin jo lähtökohtaisesti todetaan, että voidaan mukautua valmisohjelmiston tapaan toimia ja se onkin järkevää. Näkyykö tämä kirjoitetuissa vaatimuksissa? Useimmiten ei, sillä on erittäin vaikea kirjoittaa täsmällisiä ja yksikäsitteisiä vaatimuksia kiinnittämättä kuitenkaan tarpeettomia yksityiskohtia. Valmisohjelmistot eivät vaatimalla muuksi muutu. Niillä on useita asiakkaita ja ohjelmistoa kehitetään eteenpäin erilaisten asiakastarpeiden kompromissina.
Päättipä vaatimuksia kirjoittaa enemmän tai vähemmän, karkealla tai tarkalla tasolla, perustan tekemiselle luo perinteinen vaatimusmäärittelyosaaminen. Osaaminen, joka tarkoittaa kykyä kirjoittaa yksikäsitteisesti ymmärrettäviä ja testattavia vaatimuksia. Coalan kurssitarjonnassa on kursseja sekä perusteiden haltuunottoon että vaatimustenhallinnan soveltamiseen eri käyttötilanteissa.