Kuidas me rakendame nõuete analüüsi?

Kuidas näeb planeerimisprotsess välja?

Nõuete analüüs kuulub planeerimisprotsessi, mis omakorda peaks olema järgmine:

1. A projekt visioon, mis kirjeldab lõplikku toode luua.
2. Üldine tegevuskava või idee, mis sätestab, mida tuleb teha meie eesmärkide saavutamiseks.
3. Loetelu põhiülesannetest, mis määravad projekti tööetapid.
4. Ajaplaneerimine, mille käigus määratleme, mida ja millal tuleb tarnida.
5. Kolmandas etapis loodud üksikute ülesannete üksikasjalik planeerimine.

Nõuete analüüs hõlmab planeerimisprotsessi kolme esimest punkti.

Projekti visioon

Selles etapis peaksime esitama endale mõned põhiküsimused:

1. Mida me tahame teha?

Kindlasti oleme praegusel hetkel juba teadlikud sellest, mille poole me püüdleme, ning projektiidee on juba ammu esitatud ja läbi mõeldud, kuid tasub selle üle põhjalikumalt järele mõelda. Võib-olla avastame uusi teemasid, mis väärivad selgitamist. Siinkohal võivad abiks olla järgmised küsimused:

• Millist probleemi peaks see projekt lahendama?
• Kes on selle lõppkasutaja?
• Kas me loome kasutajaliidese kasutajate jaoks? Kas selle loomine on plaanis tulevikus? Kas kasutajaliidese tüüp, mida me loome (töölaua- või mobiililiides), on kindlaks määratud? Kas me hoolime RWD-st?
• Kas on olemas sarnaseid rakendusi? Millised on nende plussid ja miinused?
• Kas projekti kohta on juba loodud mingeid esialgseid kavandeid või makette?
• Kas projekt sõltub välistest rakendustest? Kas neil on või teame nende piiranguid?
• Kas me teame midagi eeldatava jõudluse ja turvalisuse taseme kohta?

2. Millised on nõuded?

Nüüd on tulnud aeg koostada projektile seatud nõuete loetelu. Lisaks funktsionaalsetele nõuetele täpsustame need, mis ei ole seotud funktsionaalsusega: kasutatavus, reageerimisvõime, kiirus, jõudlus ja turvalisus.

Olgu us kontrollige, kas iga nõue vastab järgmistele kriteeriumidele:

• on täielik - meil on selle täielik pilt,
• on õige - tõene ja oodatud,
• on teostatav - teostatav ja muud nõuded ei välista seda,
• on vajalik - see on vajalik süsteemi toimimiseks või seda nõuab klient,
• on üheselt mõistetav - loetav ja seda on võimatu valesti tõlgendada,
• on kontrollitav - pärast rakendamist on vaatluse ja katsetamise teel võimalik kindlaks teha, kas see nõue on täidetud või mitte.

3. Mis on lõplik eesmärk?

Siinkohal tasub luua lihtne visualiseering projekti toimimisest. Mitte miski ei aita projekti ideest täielikult aru saada kui põhilise voolu joonistamine või lihtsalt punktide kaupa tahvlile kirjutamine, mis omakorda peab toimuma. Kasutajaliidesega rakenduse puhul on ideaalne olukord, kui on olemas ka kõige lihtsamad maketid.

4. Millised on prioriteedid?

Nii nagu maja ehitamisel, tuleks ka IT-projektide puhul alustada alguses nullist ja siis pöörduda selle poole, mida kõige rohkem vajate. Seega tuleb alguses nõuete loetelu põhjal täpsustada loetelu kõigist võimalikest funktsioonidest, mida antud projekt täidab, ja seejärel leppida kokku, millised neist on kõige prioriteetsemad ja mida tuleb võimalikult kiiresti teostada ning millised on "nice-to-have" tüüpi.

Kogu projekti visualiseerimise etapi tulemuseks peaks olema üldine pilt sellest, kuidas projekt peaks toimima, kas siis makettide või joonistatud tegevusvoogude kaudu. Samuti peaksime saama nimekirja kõigist võimalikest funktsioonidest, mida antud projekt peab täitma, ning samuti teadma, milline on igaühe prioriteet.

Projekti visualiseerimine on võtmemoment nõuete analüüsi ajal. See aitab probleemi olemust põhjalikult mõista ja mida paremini probleemi illustreerivad materjalid, seda tõhusamad on järgmised planeerimisetapid.

Tegevuskava

Juba selles etapis määratleme, kuidas me kujutame ette projekti kui terviku toimimist. On hea, kui meil on mõned ideed elluviimiseks, mõtleme ja arutame igaühe üle ning toome välja nende nõrkused ja tugevused. Siin tasub ka valitud idee üksikasjalikult välja joonistada, kui mitte kõik.

Selles etapis on aeg kaaluda ka puhtalt tehnoloogilisi küsimusi, mitte ainult seda, millises keeles või raamistikus projekt kirjutatakse, vaid ka seda, milliseid lisavahendeid me vajame, näiteks kas me otsustame kasutada AWS korstnat või võib-olla midagi muud. Kui me kõhkleme mõne tehnoloogia vahel või ei tea, mida kasutada, siis tasub selline otsus ajas nihutada ja delegeerida uurimisülesandele. Kindlasti saame seda teha ainult siis, kui edasine planeerimine ei ole sellise uurimistööga blokeeritud. Vastasel juhul võime need julgelt ülesannetega siduda ülesannetes oleva sprint.

Peamised ülesanded

Kui oleme koostanud projektiplaani, jätkame peamiste ülesannete määratlemisega, mida seejärel arutatakse üksikasjalikult ja jaotatakse väiksemateks ülesanneteks, mida arendusmeeskond uue sprindi planeerimisel. Oluline on kirjeldada iga ülesannet võimalikult täpselt.

Kokkuvõte

Nagu eespool mainitud, sõltub nõuete analüüsi protsess projekti keerukusest. On lihtsamaid ja keerulisemaid probleeme ning on ka selliseid, mis on juba kellegi poolt lahendatud ja täiesti uusi, mille puhul tuleb pikemalt peatuda. Sellest hoolimata on mõned olulised nõuanded, mida silmas pidada:

• Kommunikatsioon. See on iga projekti elutsükli kõige olulisem osa; kõik peaks olema selgelt määratletud ja selgitatud.
• Saage kiiresti aru, mis on probleem. On tore, kui projekti dokumentatsioon on kirjutatud, kuid pidagem meeles, et see oleks võimalikult lühike ja ei võtaks tuhandeid lehekülgi. Iga arendusliikme meeskond peaks olema juurdepääs sellele ja suutma kiiresti aru saada projekti visioonist.
• Eelkõige lihtsus. Püüame teha kavandatu võimalikult lihtsaks, valime lihtsamaid lahendusi, mida on tulevikus lihtne arendada, või loobume neist, kui tekib vajadus.
• Teil ei ole seda vaja. Arvestades, et programmeerimisel juhindume YAGNI põhimõttest, siis siin on see meil tagantjärele ja me ei kiirenda liiga palju.
• Muudatused. Ärgem kartkem neid; varem või hiljem vajab iga projekt neid. Lisaks sellele ärgem petkem end sellega, et see, mida me täna planeerime, töötab igavesti. Samal ajal ei tohiks me muutusi käsitleda kui midagi halba ja ebasoovitavat. Muudatused peaksid olema parendamise sünonüümid, ja seda me tahamegi: et projekt oleks parim.
• Aeg. Ärgem laseme planeerimisel liiga kaua aega võtta ja igavesti venitada. Kui meil on probleem, mis meid blokeerib, siis otsigem lahendusi väljastpoolt või valime kõige lihtsama võimaluse.

Ülaltoodud aspekte tasub nõuete analüüsimisel alati meeles pidada, siis kulgeb see sujuvalt ja on aluseks hästi planeeritud projektile.

Loe edasi:

• Milline on parim projektijuhtimise lähenemisviis tarkvaraarendusele?
• Codesti head tavad tarkvara loomiseks. Meie lähenemine kliendi teekonnale
• Kiire juhend oma turu loomiseks ja arendamiseks. Mida tasub teada?