Kaip atlikti reikalavimų analizę?

Kaip atrodo planavimo procesas?

Reikalavimų analizė įtraukiama į planavimo procesą, kuris savo ruožtu turėtų būti toks:

1. A projektas vizija, kurioje aprašoma galutinė produktas sukurti.
2. Bendras veiksmų planas arba idėja, kurioje nurodoma, ką reikia padaryti, kad pasiektume savo tikslus.
3. Pagrindinių užduočių, kurios lemia projekto darbų etapus, sąrašas.
4. Laiko planavimas, kai nustatome, kas ir kada turi būti pristatyta.
5. Išsamus atskirų užduočių, sukurtų trečiajame etape, planavimas.

Reikalavimų analizė apima pirmuosius tris planavimo proceso punktus.

Projekto vizija

Šiame etape turėtume sau užduoti keletą pagrindinių klausimų:

1. Ką norime daryti?

Be abejo, šiuo metu jau žinome, ko siekiame, o projekto idėja jau seniai pristatyta ir apgalvota, tačiau verta apie tai pagalvoti giliau. Galbūt atrasime naujų klausimų, kuriuos verta paaiškinti. Čia gali būti naudingi šie klausimai:

• Kokią problemą šis projektas turėtų išspręsti?
• Kas bus jo galutinis naudotojas?
• Ar kuriame naudotojams skirtą sąsają? Ar jos kūrimas planuojamas ateityje? Ar nustatyta, kokio tipo sąsają (stacionariąją ar mobiliąją) kuriame? Ar mums rūpi RWD?
• Ar yra panašių programų? Kokie jų privalumai ir trūkumai?
• Ar jau sukurti kokie nors pirminiai projekto projektai ar maketai?
• Ar projektas priklausys nuo kokių nors išorinių programų? Ar jos turi arba ar žinome jų apribojimus?
• Ar ką nors žinome apie numatomą našumą ir saugumo lygį?

2. Kokie yra reikalavimai?

Dabar atėjo laikas sudaryti projektui keliamų reikalavimų sąrašą. Be funkcinių reikalavimų, nurodome ir su funkcijomis nesusijusius reikalavimus: patogumą, greitą reagavimą, greitį, našumą ir saugumą.

Tegul mus patikrinkite, ar kiekvienas iš reikalavimų atitinka šiuos kriterijus:

• yra baigtas - turime visą jo vaizdą,
• yra teisingas - teisingas ir laukiamas,
• įmanoma - įgyvendinama ir kiti reikalavimai jos nepaneigia,
• būtina - ji reikalinga, kad sistema veiktų, arba jos reikalauja klientas,
• yra nedviprasmiškas - įskaitomas ir jo neįmanoma neteisingai interpretuoti,
• galima patikrinti - įgyvendinus, stebint ir bandant galima nustatyti, ar šio reikalavimo laikomasi, ar ne.

3. Koks yra galutinis tikslas?

Čia verta sukurti paprastą projekto veikimo vizualizaciją. Niekas taip nepadeda iki galo suprasti projekto idėjos, kaip pagrindinio srauto nubrėžimas arba tiesiog taškais ant lentos užrašymas, kas turi vykti paeiliui. Jei tai programa su naudotojo sąsaja, ideali situacija - turėti net ir paprasčiausius maketus.

4. Kokie yra prioritetai?

Kaip ir statant namą, taip ir IT projektus reikia pradėti nuo nulio, o paskui imtis to, ko labiausiai reikia. Todėl pradžioje, remiantis reikalavimų sąrašu, būtina nurodyti visų galimų funkcijų, kurias konkretus projektas atliks, sąrašą ir tada susitarti, kurios iš jų turi didžiausią prioritetą ir turi būti atliktos kuo greičiau, o kurios yra “nice-to-have” tipo.

Viso projekto vizualizavimo etapo rezultatas turėtų būti bendras vaizdas, kaip projektas turėtų veikti, nesvarbu, ar tai būtų maketai, ar nubraižyta veiklos eiga. Taip pat turėtume gauti visų galimų funkcijų, kurias turi atlikti konkretus projektas, sąrašą, taip pat žinoti, kokį prioritetą turi kiekviena iš jų.

Projekto vizualizavimas yra svarbus momentas atliekant reikalavimų analizę. Ji padeda nuodugniai suprasti problemos esmę, o kuo geriau problemą iliustruojanti medžiaga, tuo efektyvesni kiti planavimo etapai.

Veiksmų planas

Šiame etape jau nustatome, kaip įsivaizduojame viso projekto veikimą. Pravartu turėti keletą įgyvendinimo idėjų, apgalvoti ir aptarti kiekvieną iš jų, išryškinti jų silpnąsias ir stipriąsias puses. Čia taip pat verta detaliai nupiešti pasirinktą idėją, jei ne visas.

Šiame etape taip pat reikia apsvarstyti grynai technologinius klausimus - ne tik kokia kalba ar sistema bus rašomas projektas, bet ir kokių papildomų įrankių reikės, pvz., ar nuspręsime naudoti AWS kamino, o gal ko nors kito. Jei dvejojame tarp kai kurių technologijų arba nežinome, ką naudoti, tuomet verta tokį sprendimą perkelti į kitą laiką ir pavesti atlikti tyrimo užduotį. Be abejo, tai galime padaryti tik tuo atveju, jei tolesnio planavimo neužkerta tokie tyrimai. Priešingu atveju juos galime drąsiai priskirti užduotims sprintas.

Pagrindinės užduotys

Sudarę projekto planą, pereiname prie pagrindinių užduočių apibrėžimo, kurias vėliau išsamiai aptarsime ir suskirstysime į smulkesnes užduotis pagal kūrimo komanda planuojant naują sprintą. Svarbu kuo tiksliau aprašyti kiekvieną užduotį.

Santrauka

Kaip minėta anksčiau, reikalavimų analizės procesas skiriasi priklausomai nuo projekto sudėtingumo. Yra lengvesnių ir sudėtingesnių problemų, taip pat yra tokių, kurias jau kažkas išsprendė, ir visiškai naujų, prie kurių reikia ilgiau stabtelėti. Nepriklausomai nuo to, yra keletas svarbių patarimų, kurių reikia nepamiršti:

• Bendravimas. Tai svarbiausias kiekvieno projekto gyvavimo ciklo komponentas; viskas turi būti aiškiai apibrėžta ir paaiškinta.
• Greitai supraskite problemą. Puiku, kad projekto dokumentacija parašyta, tačiau nepamirškime, kad ji būtų kuo glaustesnė ir neužimtų tūkstančio puslapių. Kiekvienas kūrimo narys komanda turėtų turėti prieigą prie jos ir gebėti greitai suprasti projekto viziją.
• Visų pirma paprastumas. Stenkimės, kad tai, ką planuojame, būtų kuo paprasčiau, rinkimės paprastesnius sprendimus, kuriuos ateityje būtų galima lengvai tobulinti, arba prireikus jų atsisakykime.
• Jums jos neprireiks. Atsižvelgdami į tai, kad programuodami vadovaujamės YAGNI principu, čia jį turime galvoje ir per daug nespartiname.
• Pakeitimai. Nebijokime jų; anksčiau ar vėliau jų prireikia kiekvienam projektui. Be to, neapgaudinėkime savęs, kad tai, ką planuojame šiandien, veiks amžinai. Kartu neturėtume pokyčių traktuoti kaip kažko blogo ir nepageidaujamo. Pokyčiai turėtų būti tobulinimo sinonimas, o juk būtent to ir norime - kad projektas būtų geriausias.
• Laikas. Neleiskime, kad planavimas užtruktų per ilgai ir užsitęstų amžinai. Jei turime problemą, kuri mus stabdo, ieškokime sprendimų išorėje arba rinkimės lengviausią variantą.

Analizuojant reikalavimus visada verta prisiminti pirmiau minėtus aspektus, tada viskas vyks sklandžiai ir bus gerai suplanuoto projekto pagrindas.

Skaityti daugiau:

• Koks yra geriausias projektų valdymo metodas kuriant programinę įrangą?
• "Codest" geroji programinės įrangos kūrimo praktika. Mūsų požiūris į klientų keliones
• Trumpas vadovas, kaip sukurti ir plėtoti savo rinką. Ką verta žinoti?