Miten toteutamme vaatimusanalyysin?

Miltä suunnitteluprosessi näyttää?

Vaatimusanalyysi sisältyy suunnitteluprosessiin, jonka tulisi puolestaan olla seuraava:

1. A projekti visio, joka kuvaa lopullista tuote luodaan.
2. Yleinen toimintasuunnitelma tai ajatus, jossa esitetään, mitä on tehtävä tavoitteiden saavuttamiseksi.
3. Luettelo perustehtävistä, jotka määrittävät hankkeen työvaiheet.
4. Aikataulusuunnittelu, jossa määritetään, mitä ja milloin pitäisi toimittaa.
5. Kolmannessa vaiheessa luotujen yksittäisten tehtävien yksityiskohtainen suunnittelu.

Vaatimusanalyysi kattaa suunnitteluprosessin kolme ensimmäistä kohtaa.

Hankkeen visio

Tässä vaiheessa meidän on kysyttävä itseltämme joitakin peruskysymyksiä:

1. Mitä me haluamme tehdä?

Tässä vaiheessa olemme varmasti jo tietoisia siitä, mihin pyrimme, ja hankeidea on jo pitkään esitelty ja pohdittu, mutta sitä kannattaa miettiä syvällisemmin. Ehkä löydämme uusia asioita, jotka ovat selittämisen arvoisia. Seuraavat asiat voivat olla tässä yhteydessä hyödyllisiä:

• Mikä ongelma tämän hankkeen pitäisi ratkaista?
• Kuka on sen loppukäyttäjä?
• Luommeko käyttöliittymän käyttäjille? Onko sen luominen suunnitteilla tulevaisuudessa? Onko luodun käyttöliittymän tyyppi (työpöytä- vai mobiilikäyttöliittymä) määritetty? Välitämmekö RWD:stä?
• Onko olemassa vastaavia sovelluksia? Mitkä ovat niiden hyvät ja huonot puolet?
• Onko hankkeesta jo tehty alustavia suunnitelmia tai malleja?
• Onko hanke riippuvainen ulkoisista sovelluksista? Onko niillä rajoituksia tai tunnemmeko niiden rajoitukset?
• Tiedämmekö mitään odotetusta suorituskyvystä ja turvallisuustasosta?

2. Mitkä ovat vaatimukset?

Nyt on tullut aika laatia luettelo hankkeelle asetetuista vaatimuksista. Toiminnallisten vaatimusten lisäksi määritetään ne vaatimukset, jotka eivät liity toiminnallisuuksiin: käytettävyys, reagointikyky, nopeus, suorituskyky ja turvallisuus.

Tarkistetaan, täyttääkö kukin vaatimus seuraavat kriteerit:

• on valmis - meillä on sen koko kuva,
• on oikea - totuudenmukainen ja odotettu,
• on toteuttamiskelpoinen - toteuttamiskelpoinen ja muut vaatimukset eivät kumoa sitä,
• on välttämätön - se on tarpeen järjestelmän toiminnan kannalta tai asiakkaan vaatimuksesta,
• on yksiselitteinen - luettavissa ja mahdoton tulkita väärin,
• on todennettavissa - täytäntöönpanon jälkeen on mahdollista todeta havainnoimalla ja testaamalla, onko vaatimus täytetty vai ei.

3. Mikä on lopullinen tavoite?

Tässä yhteydessä kannattaa luoda yksinkertainen visualisointi hankkeen toiminnasta. Mikään ei auta ymmärtämään täysin hankkeen ideaa paremmin kuin perusvirtauksen piirtäminen tai yksinkertaisesti kirjoittaminen taululle pisteittäin, mitä vuorollaan tapahtuu. Kun kyseessä on sovellus, jossa on käyttöliittymä, ihanteellinen tilanne on yksinkertaisimmatkin mockupit.

4. Mitkä ovat painopisteet?

Aivan kuten taloa rakennettaessa, myös tietotekniikkahankkeet on aloitettava alusta, ja sen jälkeen on siirryttävä siihen, mitä tarvitaan eniten. Alussa on siis vaatimusluettelon perusteella määriteltävä luettelo kaikista mahdollisista toiminnoista, jotka tietty hanke suorittaa, ja sovittava sitten, mitkä niistä ovat tärkeysjärjestyksessä tärkeimpiä ja ne on toteutettava mahdollisimman pian ja mitkä ovat "nice-to-have"-tyyppisiä.

Koko projektin visualisointivaiheen tuloksena pitäisi olla yleiskuva siitä, miten projektin pitäisi toimia, joko mallinnusten tai toimintojen piirretyn kulun avulla. Meidän pitäisi myös saada luettelo kaikista mahdollisista toiminnoista, jotka tietyn projektin on määrä täyttää, ja myös tietää, mikä prioriteetti kullakin niistä on.

Hankkeen visualisointi on keskeinen hetki vaatimusanalyysin aikana. Se auttaa ymmärtämään ongelman ytimen perusteellisesti, ja mitä paremmin ongelmaa havainnollistavat aineistot ovat, sitä tehokkaampia ovat seuraavat suunnitteluvaiheet.

Toimintasuunnitelma

Tässä vaiheessa määritämme jo, miten kuvittelemme hankkeen toiminnan kokonaisuutena. On hyvä, että meillä on muutama toteutusidea, mietimme ja keskustelemme niistä jokaisesta ja tuomme esiin niiden heikkoudet ja vahvuudet. Tässä kannattaa myös piirtää valittu idea yksityiskohtaisesti, jos ei kaikkia.

This stage is also time to consider purely technological issues not only in what language or framework will the project be written but also what additional tools will we need, for example, do we decide to use the AWS stack or maybe something else. If we are hesitating between some technologies or have no idea what to use, then it is worth shifting such a decision in time and delegating to a research task. Certainly, we can only do this if further planning is not blocked by such research. Otherwise, we can safely attach them to the tasks in the sprintti.

Tärkeimmät tehtävät

Kun olemme laatineet projektisuunnitelman, määrittelemme päätehtävät, joista keskustellaan sitten yksityiskohtaisesti ja jotka kehitysryhmä jakaa pienempiin tehtäviin. joukkue kun suunnittelet uutta sprinttiä. On tärkeää kuvata jokainen tehtävä mahdollisimman tarkasti.

Yhteenveto

Kuten aiemmin mainittiin, vaatimusanalyysiprosessi vaihtelee projektin monimutkaisuuden mukaan. On olemassa helpompia ja vaikeampia ongelmia, ja on myös sellaisia, jotka joku on jo ratkaissut, ja täysin uusia ongelmia, joihin on pysähdyttävä pidemmäksi aikaa. Siitä huolimatta on olemassa joitakin tärkeitä vinkkejä, jotka kannattaa pitää mielessä:

• Viestintä. Tämä on jokaisen projektin elinkaaren tärkein osa-alue; kaikki on määriteltävä ja selitettävä selkeästi.
• Ymmärrä nopeasti ongelma. On hienoa, että projektin dokumentaatio on kirjoitettu, mutta muistakaamme, että se on mahdollisimman tiivis eikä kestä tuhatta sivua. Jokainen jäsen kehitystiimi olisi päästävä tutustumaan siihen, ja heidän olisi pystyttävä nopeasti ymmärtämään hankkeen visio.
• Yksinkertaisuus ennen kaikkea. Yrittäkäämme tehdä suunnitelmistamme mahdollisimman yksinkertaisia, valitkaamme yksinkertaisempia ratkaisuja, joita voidaan helposti kehittää tulevaisuudessa, tai luopukaa niistä, kun tarvetta ilmenee.
• Et tule tarvitsemaan sitä. Ottaen huomioon, että ohjelmoinnissa meitä ohjaa YAGNI-periaate, täällä meillä on se takaraivossa emmekä kiihdytä liikaa.
• Muutokset. Älkäämme pelätkö niitä; ennemmin tai myöhemmin jokainen hanke tarvitsee niitä. Älkäämme myöskään uskotelko itsellemme, että se, mitä suunnittelemme tänään, toimii ikuisesti. Samalla meidän ei pidä suhtautua muutoksiin huonona ja ei-toivottuna asiana. Muutosten pitäisi olla synonyymi parannuksille, ja sitä me haluamme: että hanke on paras mahdollinen.
• Aika. Älkäämme antako suunnittelun kestää liian kauan ja pitkittyä ikuisesti. Jos jokin ongelma estää meitä, etsikäämme ratkaisuja ulkopuolelta tai valitkaamme helpoin vaihtoehto.

Edellä mainitut seikat kannattaa aina muistaa vaatimuksia analysoitaessa, ja silloin se sujuu sujuvasti ja on hyvin suunnitellun projektin perusta.

Lue lisää:

• Mikä on paras projektinhallintatapa ohjelmistokehityksessä?
• Codestin hyvät käytännöt ohjelmistojen rakentamiseen. Lähestymistapamme asiakaspolkuun
• Nopea opas oman markkinapaikan rakentamiseen ja kehittämiseen. Mitä kannattaa tietää?