Puhu kurkku ja opi keräämään vaatimuksia projektillesi

Hankkeen vaatimusten kerääminen on monimutkainen prosessi. Jos et tee sitä oikein, voit tuhlata sekä rahaa että aikaa. Ohjelmistokehitysyrityksen kanssa aloittavien asiakkaiden on usein vaikea määritellä tarpeitaan. Opi keräämään vaatimukset välttääksesi viestinnän epäonnistumisia projektin aloittamisen yhteydessä - riippumatta siitä, oletko asiakas tai urakoitsija -!

Vaatimukset Tekninen analyysi

Liiketoimintaongelman määritteleminen - tämä on ensimmäinen vaihe vaatimusten suunnitteluanalyysissä. Tässä tehtävässä meidän ei pitäisi keskittyä yksityiskohtiin, vaan pikemminkin ajatella ongelmaa globaalisti. Tässä on esimerkki hyvin asetetusta ongelmasta:

"Pätevien asiantuntijoiden löytäminen ICT-alalle on entistä vaikeampaa"

Toinen vaihe on löytää ratkaisu tähän ongelmaan. Se voi olla palvelu, tuote tai jopa prosessi. Seuraavaksi esimerkki ratkaisusta aiemmin esitettyyn ongelmaan voisi olla:

"SkillHunt.io-sovelluksen luominen - rekrytointiympäristö, jonka avulla sen käyttäjät saavat suuren palkkion työn ohjaamisesta ystävälleen"

Tässä vaiheessa yksityiskohdat ovat tarpeettomia. Jos arvioimme ideaa, teemme markkinatutkimuksia ja käy ilmi, että ratkaisumme on liiketoiminnallisesti perusteltua, voimme alkaa kerätä vaatimuksia. Varmistaaksemme, että he täyttävät tehtävänsä, meidän on tarkistettava, täyttävätkö ne kolme pääperustetta. Niiden on oltava:

  • Selkeä ja yksiselitteinen
  • Ymmärrettävä kaikille sidosryhmille,
  • Ajantasainen ja dokumentoitu.

Gherkin-kieltä voidaan käyttää vaatimusten keruuprosessin helpottamiseksi ja kaikkien esitettyjen kriteerien täyttämiseksi. Se on luonnollinen kieli, josta voi olla hyötyä sekä vaatimuksia kerääville yritysanalyytikoille että toiminnallisten testien skenaarioita luoville kehittäjille.

Puhu Gherkin sujuvasti

Gherkinin vaatimukset ovat yksiselitteisiä, selkeitä ja - mikä tärkeintä - helppo ymmärtää kaikille osapuolille. Tämän vuoksi keskustelu vaatimuksista on todella mahdollista.

Kuten kaikilla muilla kielillä, myös Gherkinillä on syntaksi. Sillä on tietty rakenne, joidenkin avainsanojen on oltava näkyvissä. Näin se näyttää:

Ominaisuus: Uloskirjautuminen sovelluksesta
skenaario:
   Koska olen kirjautunut sisään
   Kun napsautan “kirjaudu ulos” -painiketta
   Sitten minulle ilmoitetaan onnistuneesta uloskirjautumisesta
   Ja minut ohjataan kirjautumissivulle

Gherkiniin kerätyt vaatimukset tallennetaan .feature-tiedostoon. Tämän ansiosta kehittäjät voivat helposti käyttää näitä tiedostoja automatisoitujen testien kirjoittamiseen BDD: ssä (Behavior-based development) kurkun avulla.

Kun haluamme luoda uuden vaatimuskuvauksen, meidän on määritettävä ominaisuus, joka antaa meille uuden toiminnon nimen. Sitten jatkamme skenaarion kirjoittamista. On syytä mainita, että yksi tiedosto voi sisältää useampia kuin yhden skenaarion. Jokainen skenaario koostuu kolmesta päävaiheesta: Annettu, Milloin ja Sitten. Sanaa Seuraava kuvaus asettaa edellytykset, kun määrittelee toiminnot, jotka tapahtuvat tietyssä toiminnallisuudessa, ja kuvaa sitten toiminnan odotettavissa olevan tuloksen. Edellä esitetyssä esimerkissä on vielä yksi avainsana: Ja joka jatkaa seuraavaa menetelmää. Siksi, kun se luetellaan ajankohdan jälkeen, se jatkaisi tätä osaa ja määrittäisi toisen toiminnon. Gherkin tietää vielä yhden avainsanan: Mutta - totta puhuen koko projektipäällikköurani ajan, en ole koskaan löytänyt tilannetta, jossa sitä voitaisiin soveltaa.

Tulee sujuvaksi

Katsokaa esimerkkiä, jossa käyttäjä on kirjautunut sisään jokaisessa skenaariossa:

Ominaisuus: Valitse profiili
Tausta:
   Koska olen kirjautunut sisään
Skenaario: Ensimmäisen profiilin valinta
   Koska olen mennyt sovellukseen kirjautumisen jälkeen
   Kun minulta kysytään, minkä profiilin haluaisin valita luettelostani
   Ja valitsen profiilin luettelosta
   Sitten näen tämän profiilin kojelaudan
Skenaario: Seuraavan profiilin valinta
   Koska olen kojelaudassa
   Ja olen valinnut profiilin
   Kun valitsen avattavasta luettelosta
   Sitten näen kojelaudan tätä varten

Lisäksi, jos haluamme keskustella vaatimuksista ja tulevaisuudessa testata useampaa kuin yhtä skenaariota, kannattaa käyttää joitain esimerkkejä - käyttämällä Esimerkki-toimintoa. Tietojen kerääminen tässä muodossa on usein yksiselitteisin. Jos haluat käyttää esimerkkiä, meidän on laitettava muuttuja sisäkulmasulkeisiin <> ja asetettava taulukot skenaarion alapuolelle. Meidän on muistettava, että jos käytämme esimerkkejä, skenaarioidemme tulisi nimetä Skenaario-ääriviivat. Seuraavan esimerkin pitäisi tehdä selväksi:

Ominaisuus: Kirjaudu sovellukseen
Tausta:
   Koska olen rekisteröitynyt käyttäjä
   Ja tilini on aktivoitu
Skenaarion ääriviivat: Onnistunut kirjautuminen
   Koska olen kirjautumissivulla
   Kun täytän "kirjautuminen" painikkeella 
   Ja täytän "salasanan" 
   Ja napsautin "Kirjaudu" -painiketta
   Sitten minut ohjataan sivulle, jossa valitaan profiili
esimerkkejä:
   | kirjaudu sisään oikea salasana |
   | Lukasz | Gh3rk1n |
   | Arek | Cucumb3r |
Skenaarion ääriviivat: epäonnistunut sisäänkirjautuminen
   Koska olen kirjautumissivulla
   Kun täytän "kirjautuminen" painikkeella 
   Ja täytän "salasanan" 
   Ja napsauta "Kirjaudu" -painiketta
   Sitten minulle ilmoitetaan epäonnistuneesta kirjautumisesta
esimerkkejä:
   | kirjaudu sisään väärä salasana |
   | Lukasz | Kurkku |
   | Arek | Kurkku |
Skenaario: Luvaton tulo
   En ole kirjautunut sisään
   Kun yritän siirtyä Hallintapaneeli-sivulle
   Sitten minut ohjataan kirjautumissivulle

Ketterissä projekteissa vaatimukset muuttuvat tietysti. On tarpeen soveltaa muutoksia .feature-tiedostoihin ja siksi - käynnissä olevat muutokset sovellustesteissä. Tällä tavalla voimme pitää dokumentointimme ajan tasalla. Tehtävien suorittaminen skenaarioiden mukaisesti johtaa toimittamiseen ja ajamiseen elementtejä, jotka sopivat täydellisesti ketterän johtamisen periaatteisiin.

___

Alun perin julkaissut Łukasz Nowacki osoitteessa neoteric.eu/blog 20. lokakuuta 2016.