Voitot:
- Kyky erottaa toiminnalliset ja ei-toiminnalliset vaatimukset ja kirjoittaa selkeitä, mitattavia vaatimuslausekkeita tekoälyn tuella
- Mahdollisuus käyttää tekoälyä jäsenneltyjen kehotteiden avulla poimimaan käyttäjien tarinat, hyväksymiskriteerit ja laajuuden rajat haastattelumuistiinpanoista
- Tottuu tapana tarkistaa tekoälyn luomat vaatimukset epäselvyyden, ristiriidan ja puuttuvien sääntöjen varalta ja vahvistaa ne sidosryhmien kanssa
Vaatimusanalyysin tehtävänä on määritellä täydellisesti, selkeästi ja todennettavissa olevalla tavalla, mitä järjestelmän tulee tehdä. Se on yksi vaiheista, jossa MIS-asiantuntija tuottaa eniten arvoa; koska tässä virhe kasvaa eksponentiaalisesti projektin lopussa. Vaatimusanalyysin perustyyppejä on kaksi. Toiminnallinen vaatimus kuvaa työtä, jonka järjestelmän tulee tehdä: "Järjestelmän tulee lähettää asiakkaalle sähköposti, kun se vahvistaa tilauksen." Ei-toiminnallinen vaatimus kuvaa, millainen järjestelmän tulee olla: ominaisuuksia, kuten suorituskyky, turvallisuus, käytettävyys ja saavutettavuus. "Raporttinäytön pitäisi avautua alle 2 sekunnissa keskimääräisellä kuormituksella" on ei-toiminnallinen vaatimus.
Hyvällä vaatimuksella on kolme ominaisuutta: se on selkeä (sillä on yksi tulkinta), se on mitattavissa (sillä on testattava kynnys) ja se on jäljitettävissä (on selvää, mistä liiketoiminnan tarpeesta se tulee). "Järjestelmän on oltava nopea" ei täytä mitään näistä; "nopea" on subjektiivinen, sitä ei voida mitata, ei voida testata. Tässä vaiheessa tekoäly on tehokas apu vaatimusten laadinnassa ja monitulkintaisen sanamuodon löytämisessä; mutta vain sidosryhmä päättää, mikä liiketoimintasääntö on todellinen.
Käyttäjän tarina ja hyväksymiskriteerit
Yleinen muoto nykyaikaisessa vaatimuskirjoituksessa on käyttäjäkertomus: "[roolina], [tarkoitukseen], haluan [ominaisuuden]." Esimerkki: "Myynnin edustajana haluan alennuslaskelman mobiilinäytöltä, jotta voin tehdä pikatarjouksia kentällä." Tarina on lyhyt ja liiketoiminnallinen; Se ei vaadi teknistä ratkaisua.
Jokaisella tarinalla tulee olla hyväksymiskriteerit: testattavat ehdot, jotka on täytettävä, jotta tarinaa pidettäisiin "ok". Usein käytetty malli on "Annettu/Kun/Sitten" -malli: "Tietytty: asiakas on VIP-segmentissä. Milloin: yli 10 000 TL tilaukset. Sitten: järjestelmä antaa 5% alennuksen." Tämä malli eliminoi epäselvyyden, koska se yhdistää selvästi tilan ja odotetun tuloksen.
Vinkki: Kun kirjoitat käyttäjätarinaa tekoälylle, muista sanoa "luo vähintään 2 hyväksymiskriteeriä muodossa Annettu/Milloin/Sitten jokaiselle tarinalle". Kun malli pakotetaan tuottamaan vertailuarvoja, vaatimuksissa näkyvät piilotetut aukot.
Askel askeleelta: AI-avusteinen vaatimusten purkaminen
Vaihe 1 – Kerää raakasyöttö. Puhelulokit, sähköpostit, olemassa olevat kuvakaappaukset, valitusluettelot. Mitä enemmän todellista panosta, sitä vähemmän valmistusta.
Vaihe 2 – Pura ensimmäiset tarinat. Anna tekoälylle raakapanos ja anna sen tuottaa käyttäjätarinaluonnoksia. Tämä vaihe ei ole täydellinen luettelo, vaan ensimmäinen askel.
Vaihe 3 – Lisää hyväksymiskriteerit. Luo Annettu/Milloin/Sitten kriteerit kullekin tarinalle. Tarina, jolle ei voida tuottaa kriteerejä, tarkoittaa itse asiassa, että sitä ei ole määritelty tarpeeksi.
Vaihe 4 – Etsi ristiriitoja ja aukkoja. Kysy tekoälyltä: "Onko näiden vaatimusten välillä ristiriitoja, päällekkäisyyksiä tai määrittelemättömiä tilanteita?" Kysy ja tarkista asia. Suodata tulos ihmisenä.
Vaihe 5 – Priorisoi ja vahvista. Priorisoi tarinoita sidosryhmien kanssa liiketoiminnan arvon ja kiireellisyyden perusteella. Ensisijainen päätös kuuluu liiketoimintayksikölle, ei tekoälylle.
Älä unohda ei-toiminnallisia vaatimuksia
Suurin osa projekteista on alalla vaikeuksia, koska ne unohtavat ei-toiminnalliset toiminnallisia vaatimuksia kirjoitettaessa. Raportti voi toimia "oikein", mutta jos sen avaaminen kestää 45 sekuntia, kukaan ei käytä sitä. Seuraavassa taulukossa on esitetty yleisesti huomiotta jätetyt ei-toiminnalliset vaatimustyypit ja mitattavissa olevat kirjoitusesimerkit.
Genre
huono ilmaisu
mitattavissa oleva ilmaisu
Suorituskyky
"On oltava nopea"
"Kyselyn vastaus < 2 sekuntia keskimääräisellä kuormituksella"
saavutettavuus
"Kaikkien pitäisi pystyä käyttämään sitä"
"WCAG 2.1 AA -yhteensopiva; täydellinen näppäimistönavigointi"
Turvallisuus
"Sen pitäisi olla turvallista"
"Henkilökohtaiset tiedot on salattu lepotilassa; pääsy on roolipohjaista"
saatavuus
"Pitäisi olla helppoa"
"Uusi käyttäjä suorittaa tilauksen kolmessa vaiheessa ilman koulutusta"
Saatavuus/jatkuvuus
"Ei pitäisi kaatua"
"Kuukausittainen käyttöaika ≥ 99,5 %"
Kolme minikoteloa: Numeroiden mukaan
Tapaus 1 – mittaamattoman tarpeen hinta. Näyttö, joka on kehitetty pankissa vaatimalla, että "raporttinäytön pitäisi avautua nopeasti", avautui 22 sekunnissa kenttäkuormituksessa. Kehittäjä luuli tarjoavansa sanan "nopea" ympäristöönsä (2 sekuntia). Jos vaatimukseksi olisi kirjoitettu "< 3 s huipputunnilla, todellinen läpijuoksu", ongelma olisi jäänyt kiinni testaukseen. Uudistus maksoi 3 viikkoa ja mitattavissa olevat lisäkustannukset.
Tapaus 2 – Hyväksymiskriteerien mukainen aukko. Kirjoittaessaan verkkokauppaprojektissa "Järjestelmä soveltaa alennusta" -tarinan hyväksymiskriteerejä sidosryhmä huomasi, että mitä tapahtuisi, jos alennus olisi ristiriidassa kupongin ja VIP-alennuksen kanssa, ei keskusteltu ollenkaan. Yksi Annettu/Kun/Silloin-kysymys esti kaksinkertaisen alennusvirheen ennen käyttöönottoa; Tämä virhe aiheutti vakavia tulonmenetyksiä vastaavissa projekteissa.
Tapaus 3 – tekoälyn tekemä sääntö. Eräässä HR-projektissa tekoäly lisäsi vaatimusluonnokseen lauseen "lomapyyntö hyväksytään automaattisesti 24 tunnin sisällä". Kokouksessa ei käsitelty tällaista automaattista hyväksyntää; Malli oli laatinut säännön, joka vaikutti "järkevältä". Jokaisen vaatimuksen viereen asiantuntija kirjoittaa "lähde: mikä haastattelu/asiakirja?" Lisäämällä sarakkeen hän poisti 4 lähdettä sisältämätöntä lausetta.
Heikko kehote / Vahva kehote
Heikko kehote:
Kirjoita käyttäjätarinoita tälle projektille.
Tehokas kehotus:
Roolisi: Olet MIS-liiketoiminnan analyytikko. Pura käyttäjien tarinoita alla olevasta haastattelumuistiinpanosta. Säännöt:- Muoto: "[roolina], [tarkoituksena], haluan [ominaisuuden]."- Kirjoita VÄHINTÄÄN 2 hyväksymiskriteeriä jokaiselle tarinalle Annettu/Milloin/Silloin-muodossa.- Lisää "Lähde"-sarake jokaisen jutun viereen. huomautus; sovitus.- Kirjoita erilliseen kohtaan mitattavissa olevat ei-toiminnalliset vaatimukset (suorituskyky, turvallisuus, saavutettavuus). Haastatteluhuomautus:[text]
Tehokas kehote vahvistaa tarinan muodon, hyväksymiskriteerit, lähteen jäljitettävyyden ja ei-toiminnalliset vaatimukset kerralla; Tämä helpottaa lähdön hallintaa.
Neljä kopioitavaa mallia
1) Vaatimusten selvennys:
Tarkista alla oleva vaatimus. Merkitse jokainen väite, joka on epämääräinen, suhteettoman suuri tai avoin useammalle kuin yhdelle tulkinnalle, ja kirjoita jokaiselle selventävä kysymys. Älä keksi vastausta. Vaatimus: [teksti]
2) Ristiriitaskannaus:
Etsi alla olevasta vaatimusluettelosta kohteita, jotka ovat ristiriidassa keskenään, toistuvat tai jättävät loogisia aukkoja. Ilmoita jokaisesta löydöstä nimikenumerot ja yhden lauseen perustelut. Lista: [teksti]
3) Hyväksymiskriteerien luominen:
Kirjoita vähintään 4 hyväksymisehtoa seuraavalle käyttäjätarinalle Annettu/Kun/Silloin-muodossa, mukaan lukien raja- ja poikkeustapaukset. Listaa myös kaikki epäselvät kohdat. Tarina: [teksti]
4) Laajuus:
Laadi "Sovellessa"- ja "Out of Scope" -kohteet kaksisarakkeiseksi taulukoksi seuraavien vaatimusten mukaisesti. Merkitse [VAHVISTUS VAATII] mille tahansa tuotteelle, josta olet epävarma. Vaatimukset: [teksti]
Yleisiä virheitä
- Ratkaisun ajatteleminen on tarve. "Lisää avattava valikko" on ratkaisu, ei vaatimus. Vaatimus sanoo "käyttäjän on voitava valita maa määritetystä luettelosta"; IT-tiimi suunnittelee ratkaisun.
- Ei-toimivien väliin. Pelkästään "mitä tehdä" kirjoittaminen ja "miten olla" unohtaminen (nopeus, turvallisuus, saavutettavuus) on yleisin ja kallein porsaanreikä.
- Käyttämällä mittaamattomia adjektiiveja. Sanat, kuten "nopea, helppo, turvallinen, käyttäjäystävällinen" ovat virheellisiä ilman kynnystä.
- Ei huomaa tekoälyn laatimaa sääntöä. Malli voi lisätä "järkeviä", mutta ei todellisuudessa puhuttuja sääntöjä; Pyydä resursseja jokaiseen tarpeeseen.
- Priorisoinnin jättäminen tekoälylle. Mitä tehdä ensin, on liiketoiminnan arvopäätös; Liiketoimintayksikkö antaa tämän.
Varoitus: Vaarallisuusanalyysin vaarallisin lause on "kaikki jo tietävät tämän". Puhumattomat oletukset eivät pääse dokumentaatioon, eivät koskaan pääse koodiin, vaan tulevat esiin kentällä. Kysy tekoälyltä "mitä tässä vaatimuksessa oletetaan, mutta ei kirjoitettu?" tekee nämä piilotetut oletukset näkyväksi.
Yhteenvetona
Vaatimusanalyysi määrittelee, mitä järjestelmän tulee tehdä selkeällä, mitattavissa ja jäljitettävällä tavalla. Toiminnalliset vaatimukset kuvaavat työtä, ei-toiminnalliset vaatimukset kuvaavat ominaisuuksia, ja jälkimmäinen usein unohtuu. Käyttäjätarina ja Annettu/Kun/Silloin hyväksymiskriteerit ovat tehokkaita työkaluja, jotka poistavat epävarmuuden. Tekoäly nopeuttaa merkittävästi kuvakäsikirjoituksen, hyväksymiskriteerien, konfliktien havaitsemisen ja selvittävien kysymysten tuotantoa; Liiketoiminnan säännön oikeellisuus, laajuus ja prioriteettipäätös sekä jokaisen lauseen lähde ovat kuitenkin ihmisen vastuulla. Älä viimeistele vaatimuksia, jotka ovat lähtemättömiä ja mittaamattomia.
Sovellustehtävä
Kirjoita yhden kappaleen yrityspyyntö kuvitteellisesta "online-ajanvarausjärjestelmästä" (esim. "Asiakkaiden pitäisi voida varata aikoja verkossa, henkilöstön pitäisi pystyä näkemään kalentereita"). (1) Luo vähintään 5 käyttäjätarinaa ja 2 hyväksymisehtoa kullekin tämän pyynnön vahvalla kehotuksella. (2) Etsi vähintään 2 piilotettua aukkoa mallin tuottamissa kriteereissä (esim. kaksinkertainen tapaaminen samanaikaisesti, peruutussääntö). (3) Sisällytä vähintään kolme ei-toiminnallista vaatimusta mitattavissa olevassa muodossa. (4) Ilmoita vähintään 3 kohdetta "soveltamisalan ulkopuolella". (5) Merkitse mallin mahdollisesti keksimä sääntö ja kirjoita miten vahvistaisit sen.
tarkistuslista
- [ ] Kirjoitin toiminnalliset ja ei-toiminnalliset vaatimukset erikseen.
- [ ] Jokainen vaatimus on selkeä, mitattavissa ja testattavissa.
- [ ] Jokaisella tarinalla on Annettu/Milloin/Sitten hyväksymiskriteerit.
- [ ] Pystyn jäljittämään jokaisen vaatimuksen lähteen (keskustelun/asiakirjan).
- [ ] Merkkasin mahdolliset tekoälyn keksimät säännöt ja jätin ne varmistukseksi.
- [ ] Tein priorisoinnin yhdessä liiketoimintayksikön kanssa.