Vaatimusmäärittely on tuntunut viime vuosikymmenen aikana unohtuneen ja menettäneen merkityksensä. Agile-kulttuuri vei fokuksen storeihin ja sprintteihin, ja “vaatimusmäärittely” alkoi kuulostaa vesiputousmallilta.
Paradoksi on, että backlogin sisällön kirjoittaminen on määrittelytyötä, sitä ei vain enää kutsuttu sillä nimellä. Vaatimusmäärittely erillisenä ammattitaitona jäi varjoon, mutta nyt viimeisen vuoden aikana siitä on jälleen keskusteltu enemmän kuin koskaan. Ohjelmistokehityksen puolella on noussut esiin määrittelylähtöinen kehitys (spec-driven development), jossa tekoälyavusteinen koodaus nojaa huolellisesti kirjoitettuun määrittelyyn.
Vaatimusmäärittely on tapetilla siksi, että tehostumisen myötä järjestelmäprojektien pullonkaula on siirtynyt toteutuksesta määrittelyyn ja toisaalta laadunvarmistukseen, eli testaamisen prosessiin.
Keskusteluissa on pinnalla kaksi eri kysymystä:
- Miten tekoäly voi vauhdittaa vaatimusmäärittelytyötä?
- Miten määrittelyt voi tehdä “tekoälyoptimoidusti” niin, että tekoälyavusteinen koodaaminen onnistuisi mahdollisimman hyvin?
Miten tekoäly voi vauhdittaa vaatimusmäärittelytyötä?
Kun määritellään tietojärjestelmävaatimuksia (tai kirjoitetaan featureita ja storyja eli backlogiin sisältöä), tarkoitan tässä blogissa uusien määritysten kuvaamista. Määritellään uusia toiminnallisuuksia, liiketoimintasääntöjä tai esimerkiksi uuteen lainsäädäntöön liittyviä vaatimuksia.
Uuden määrittely on tärkeää erottaa vanhan järjestelmän kopioimisesta, jossa järjestelmä uudistetaan vaihtamalla teknistä alustaa. Teknisen alustan vaihdossa vaatimusmäärittelytyötä ei sanan varsinaisessa mielessä tehdä ollenkaan, vaan määrittely tehdään kopioimalla vanhan järjestelmän vaatimukset.
Tekoäly on vanhan järjestelmän vaatimusten kopioinnissa merkittävä apu: olemassa olevan järjestelmän koodista saadaan melko vaivattomasti pohja vaatimuksille, tai koodi voidaan kääntää suoraan uudelle ohjelmointikielelle. Vanha koodi on kuitenkin käytännössä aina puutteellista ja sisältää virheitä, joten ihmisen on käytävä tekoälyn tuottama pohja läpi, täydennettävä sitä ja korjattava loogiset virheet.
Toiminnallisuudeltaan uuden järjestelmän määrittelytyössäkin tekoälyn mahdollisuudet ovat moninaiset:
- Tekstin käsittely. Määrittelyt ovat suurimmaksi osaksi tekstiä. Sitä voi siis tekoälyn avulla esimerkiksi summeerata, sujuvoittaa, pakottaa tiettyyn rakenteeseen, kääntää eri kielelle.
Tiketöintijärjestelmissä on sisäänrakennettunakin kirjoitusapureita, jotka auttavat vaikkapa vaatimusten yhteneväisyydessä rakenteen ja sanaston suhteen, tai auttavat generoimalla uusia vaatimusaihioita ja -ehdokkaita kielimallin ”oman” tietämyksen pohjalta.
- Ryhmätyön tai haastattelujen tuotosten litterointi ja muuttaminen vaatimuksiksi. Vaatimusmäärittelyjen tekeminen vaatii lähes aina ryhmätyötä: työpajoja tai haastatteluita. Nämä tapaamiset tai haastattelut voi litteroida, ja antaa tekoälyn puristaa keskustelusta vaatimukset, eli featuret ja storyt.
- Vaatimusten generoiminen olemassa olevasta dokumentaatiosta. Määrittelyjä voi myös johtaa tekoälyn avulla laajasta määrästä olemassa olevaa dokumentaatiota: esimerkiksi prosessidokumenteista, laki- tai sopimusasiakirjoista, sisäisistä toimintatapaohjeista, integraatiokuvauksista ja tietomalleista.
- Vaatimusmäärittelytyön tekeminen tekoälyn johdolla. Määrittelytyötä voidaan tehdä yhdessä tiiminä niin, että tekoälyn annetaan fasilitoida ja johtaa keskustelua, esittää hyviä kysymyksiä. Kysymyksiin vastataan yhdessä tiiminä ja annetaan vastaus tekoälyn analysoitavaksi.
- Tiimin yhteisten promptien, agenttien ja skillien käyttö: Esimerkiksi
- Agentti, joka tarkistaa featuret definition of ready -kriteeristöä vasten ja validoi esimerkiksi vaatimuksen yksiselitteisyyden, testattavuuden ja mitattavuuden.
- Agentti, joka muuttaa toisiinsa linkittyvät vaatimukset tai storyt prosessikuvaukseksi.
- Agentti, joka järjestää featuret tai storyt prioriteettijärjestykseen määritellyllä kriteeristöllä esimerkiksi SAFen WSJF (Weighted Shortest Job First).
- Agentti, joka vertailee vaatimusta eri lähteisiin, esimerkiksi tietomalliin ja tekee tämän perusteella jatkokysymyksiä tai sparrausta.
Haluaisin korostaa sitä, että vaatimusten tuottaminen vaatii edelleen keskustelua eri osapuolten välillä. Piuhaa ei voi vielä vetää suoraan eri osapuolten aivoista toiseen ja antaa yhteisen aivokemian tuottaa vaikkapa uusia liiketoimintasääntöjä.
Miten tehdä vaatimusmäärittelyt tekoälyoptimoidusti?
Määrittelyä seuraa ratkaisun toteutus, koodaaminen tai konfiguroiminen.
Tekoälyavusteisessa koodaamisessa annetaan tekoälylle prompti, joka voi olla suoraan hyvin tehty määrittelydokumentaatio. Mitä parempilaatuisia määrittelyt ovat, sitä parempaa koodia voidaan tekoälyavusteisesti tuottaa.
Vielä ei kuitenkaan voi antaa yleispäteviä, tarkkoja formaattiohjeita tekoälyoptimoituun määrittelydokumentaatioon. Vastaus riippuu koodauksessa käytetystä alustasta ja sen kielimallista, toteutettavista toiminnallisuuksista ja jopa koodarin toimintatavoista. Ei voida siis sanoa, että juuri tämä rakenne, struktuuri tai Definition of Done tuottaa aina täysin tarpeiden mukaista koodia.
Tekoälyoptimoitu määrittely kuulostaa uudelta kysymykseltä, mutta vastaus on yllättävän tuttu: laadukas määrittely tuottaa hyvää koodia riippumatta siitä, koodaako ihminen vai tekoäly.
Tekoälyavusteinen koodaaminen vaatii määrittelyiltä erittäin korkeaa laatua
Määrittelyjen korkean laadun vaatimus johtuu siitä, että ihmiskoodari osaa kysyä, jos jokin vaatimuksissa jää epäselväksi. Tekoäly ei välttämättä kysy, vaan se arvaa. Arvaus voi olla uskottavan kuuloinen, mutta väärä. Tämä nostaa yksiselitteisyyden vaatimusta: mitä vähemmän tulkinnanvaraa määrittelyssä on, sitä vähemmän tekoäly pääsee täyttämään aukkoja omilla oletuksillaan.
Ennen kuin ollaan hyvässä promptausvalmiissa määrittelyssä, ollaan kuljettu jo pitkä matka asiakkaan, liiketoiminnan ja muiden sidosryhmien tarpeista, ongelmista ja tavoitteista lähtien. Matkalla on muistettava perusasiat, vanhat lähes ikiaikaiset vaatimusmäärittelyn ohjeet:
- Vaatimus johdetaan eri sidosryhmien tarpeista ja tavoitteista
- Vaatimuksen avulla ratkaistaan jokin tunnistettu ongelma
- Vaatimus on yksiselitteinen kuvaus, mitä tietojärjestelmältä halutaan ja miksi
- Yksi vaatimus sisältää vain yhden asian
- Vaatimus on selkokielinen ja ymmärrettävä
- Vaatimus on testattavissa tai todennettavissa
- Vaatimus on realistinen ja toteutettavissa
Tekoälyavusteisessa koodauksessa toimivat hyvin myös testitapaukset: ohjataan tekoälyä tuottamaan koodia, joka täyttää annetut testit. Tämä noudattaa tuttua testivetoisen kehityksen (TDD, test-driven development) periaatetta, joka sopii erityisen hyvin yhteen kielimallien kanssa.
Hyvistä määrittelyistä saa tekoälyn avulla helposti testitapauksia, ja avainasemassa ovat tässäkin ennen kaikkea erinomaisen laadukkaat määrittelyt. Tässäkin on toki oma riskinsä: tekoälyn tuottama koodi voi läpäistä testit, mutta ei toimi oikein testitapausten ulkopuolella.
Ihminen ratissa
Vaikka tekoälyn pystyy tarjoamaan laajaa apua määrittelyyn, ihmisen rooli ei katoa. Täysin automatisoidusti määrittelyjä ei voi eikä kannata tehdä.
Määrittelijältä vaaditaan kokemusta ja ammattitaitoa. Tekoäly voi auttaa kokemattomampaa vaatimusmäärittelijää, esimerkiksi liiketoiminnan asiantuntijaa, tuottamaan jäsennellympiä ja selkeämpiä vaatimuksia. Tekoäly ei kuitenkaan korvaa kokemusta. Aloittelijalta jäävät helposti kokonaan huomaamatta esimerkiksi ei-toiminnalliset vaatimukset ja muut reunaehdot, joita tekoälykään ei osaa itsestään kysyä.
Ihminen ja erityisesti ihmisten välinen vuorovaikutus on edelleen välttämätöntä esimerkiksi seuraavissa tapauksissa:
- Innovaation, kilpailuedun ja erottautumistekijöiden keksimisessä. Tekoäly toistaa opetusmateriaalin asioita, ei tuota uutta.
- Sääntelyn lopullisessa tulkinnassa. Regulaatiota voi tulkita monella eri tavalla, ja vasta aika näyttää millaiseksi tulkinta vakiintuu. Varsinkin uuden lainsäädännön kohdalla tekoälyn vaatimaa opetusmateriaalia ei yksinkertaisesti ole vielä olemassa.
- Lopullisessa toiminnallisuuksien välisessä priorisoinnissa. Tekoäly voi ehdottaa, mutta priorisointipäätös ja hyväksyntä on ihmisen tehtävä.
- Eri osapuolten välisten ristiriitojen ratkaisemisessa. Tekoäly voi kyllä ehdottaa kompromissia ja osoittaa empatiaa. Se ei kuitenkaan ymmärrä sanatonta viestintää tai osaa sovitella.
- Hiljaisen tiedon tulkitsemisessa. Jos asiat eivät ole dokumentoitu, tekoäly on voimaton.
Näiden kysymysten ratkaiseminen vaatii ihmisten välistä vuorovaikutusta, ei tekoälyä.
Tekoäly on erinomainen työkalu määrittelytyössä. Se tekee määrittelystä teknisesti helpompaa, mutta se tekee samalla ihmisen roolista vaativampaa. Tärkeintä on investointi määrittelyosaamiseen, ei tekoälytyökaluihin.
