Kuidas rakendada nõuete haldustööriista

Kuidas rakendada nõuete haldustööriista

Sisukord

Kuidas rakendada nõuete haldustööriista?

Nõudehaldustööriista rakendamiseks peate tegema mitu sammu.

Esiteks peate tuvastama tööriista sidusrühmad ja kasutajad. See hõlmab projektijuhte, ärianalüütikuid, arendajaid, testijaid ja teisi inimesi, kes seda kasutavad. Samuti peate selle suuruse, projektide keerukuse ja muude tegurite põhjal kindlaks määrama, millist tüüpi nõuete haldussüsteem on teie organisatsiooni jaoks parim.

Järgmisena peaksite otsustama, millist tarkvaratööriista või platvormi soovite oma nõuete haldamise protsessis kasutada. Tänapäeval on turul saadaval palju erinevaid tüüpe, näiteks Visure. Kui olete otsustanud, milline neist teie organisatsiooni vajadustele kõige paremini sobib, on aeg süsteem seadistada. See võib hõlmata kasutajakontode loomist, juurdepääsutasemete seadistamist erinevatele kasutajatele ja seadete konfigureerimist, et tagada tarkvara nõuetekohane funktsionaalsus.

Kui teie nõuete haldustööriist on õigesti seadistatud, on aeg seda kasutama hakata! Peaksite määratlema mallid sidusrühmadelt nõuete kogumiseks ja korraldamiseks. Lisaks peaksite looma protsessi ja reeglistiku, mis tagab, et iga nõue on õigesti dokumenteeritud, nii et neid jälgitakse vastavalt kogu selle elutsükli jooksul. Lõpuks peaksite looma ülevaatusprotsessi, et kõik nõude muudatused või värskendused vaadataks enne rakendamist korralikult üle.

Miks vajate nõuete haldustööriista?

Pole saladus, et kehvad nõuded toovad kaasa ebakvaliteetsed tooted ja et need projektid on sageli täis ulatust. Dokumendipõhise lähenemisega nõuetele on palju väljakutseid, sealhulgas asjaolu, et pidevalt muutuvas tarkvaraarenduses on neid keeruline ajakohasena hoida. Isegi kui olete kasutajate nõuete kogumisel ja dokumenteerimisel teinud suurepärast tööd, on nõuete haldamine alles alanud.

Siin on mõned peamised põhjused automatiseeritud nõuete haldamise tööriista kasutamiseks vastavalt Karl Wiegersile (www.processimpact.com artikkel nõuete haldamise automatiseerimisest).

Hallake versioone ja muudatusi. Enamik süsteeme avaldatakse tänapäeval iteratiivsel (või paindlikul) viisil. See tähendab, et nõuetel on väljalaskega seotud versioonid. Võimalus jälgida muutusi ja tuvastada muudatuste mõju muudatuste kontrollimisel ja ulatuse roomamisel.

Salvestage nõuete atribuutides lisateavet. Peale nõude avalduse peame muu nõude kohta teadma palju muud. Näiteks nõuete olek, prioriteet, kes seda taotles ja testi olek. Need on vaid mõned soovitused.

Nõuded siduda teiste süsteemielementidega. Tagamaks, et kõik nõuded on toote osa, kõiki nõudeid testitakse, muudatusi hinnatakse jne, peame suutma nõudeid siduda teiste süsteemielementidega.

Raja olek. Mõelge sellele, et saaksite koostada nimekirja kõigist heakskiitmata nõuetest, kõigist nõuetest, mis ei ole seotud madalama taseme nõuetega, ja kõigist nõuetest, mida ei testita. See on seda tüüpi teave, mis aitab meil projekti olekut tõeliselt teada saada.

Vaadake nõuete alamhulka. Mõelge sellele, et saaksite vaadata kõiki kõrge prioriteediga nõudeid, millele pole määratud katsemeetodit. Või turvabüroo, kes soovib üle vaadata ainult turvalisusega seotud nõuded. Võimalus filtreerida nõudeid nii, et see hõlmaks ainult teavet, mida kasutaja näeb, vähendab nende nõuete ülevaatamiseks kuluvat aega.

Juurdepääsu juhtimine. Te soovite veenduda, et ärianalüütikud saavad muuta ainult kasutaja nõudeid; süsteemianalüütikud saavad muuta ainult süsteeminõudeid ja nii edasi. Pärast heakskiitmist peab juurdepääs nõuetele olema piiratud, et ilma ülevaatuseta ei saaks teha täiendavaid muudatusi.

Suhtle sidusrühmadega. Muudatustest teavitamine on oluline tagamaks, et sidusrühmad on kõigist võimalikest muudatustest teadlikud. Enamik nõuete haldamise tööriistu aitab seda tüüpi teatisi automaatselt edastada.

Neil meist, kes on kasutanud nõuete haldamise tööriistu, on raske ette kujutada, et läheks tagasi selle töö juurde paberil. Ja ma usun, et vähesed meist otsustavad selle meetodi juurde tagasi pöörduda. Mina isiklikult võtaksin kõik nõuete haldamise tööriistad üle dokumendipõhise lähenemisviisi. Minu jaoks on aga hämmastav, et paljud igas suuruses organisatsioonid toetuvad oma nõuete haldamisel jätkuvalt dokumendipõhistele tööriistadele. Nõuete haldamise tööriista kasutamine on esimene samm nõuete üle kontrolli saamiseks.

Enne nõuete haldustööriista ostmist...

Pole saladus, et professionaalsete nõuete insenerilahendused aitavad nõuetega töötamisel tõhusust tõsta. Samuti aitavad need minimeerida vigade arvu, mis arendustegevuse elutsükli hilisemates faasides viivad tavaliselt kulukate parandusteni. 

Seetõttu otsivad paljud ettevõtted selliseid nõuete insenerilahendusi, kuid paraku kehtib ka nõuete insenertehniliste lahenduste puhul sama reegel, mis peaaegu kõigi muude tarkvaratööriistade puhul: loll tööriistaga jääb lolliks...

Oma klassi parimad nõuete insenerilahendused, nagu platvorm Visure Requirement ALM, on väga paindlikud, et toetada peaaegu igat tüüpi nõuete kavandamise protsesse. Muidugi müüme teile tööriistamüüjana hea meelega tarkvara, kuid oleme veendunud, et see üksi teid ei aita. Selle asemel tahame aidata teil meie tooteid edukalt kasutada.

Seega veenduge enne nõuete insenerilahenduse ostmist, et teil on nõuetekohane nõuete kavandamise protsess koos teatud rollidega määratud teatud tegevustega. Loomulikult saame ka teiega selles vallas oma kogemusi jagada. Kui teate oma protsessi üksikasjalikke omadusi, on teil palju lihtsam leida sobiv lahendus, mis sobib teie protsessi vajadustega.

6 näpunäidet nõuete haldamise tööriista edukaks rakendamiseks

Aastaid tagasi töötasin mitu aastat väga keerulise relvajuhtimissüsteemi kallal. Nagu võite ette kujutada, olid nõuded suured, keerulised ja sageli muutunud. Veetsime palju aega lihtsalt nende tüütute muudatuste haldamiseks, mida nii klientidelt kui ka arendajatelt jätkuvalt esitati. Neil algusaegadel ei olnud meil nõuete haldamise tööriistu, mis aitaksid neid muudatusi hinnata. Kasutasime Interleafi ja Excelit (nüüd kuulen valu oigamist). Kõik oli käsitsi, sealhulgas meie keeruline jälgitavus. Meil oli paar inimest, kes ei teinud muud, kui säilitasid jälgitavuse maatriksid ja hindasid muudatuste mõju. Sel ajal oli meil ainult jälgitavus alates toimingute kontseptsioonist kuni süsteeminõueteni kuni alamsüsteemi nõueteni. Ma ütlen "ainult", kuid sel ajal oli lihtsalt sellisel tasemel jälgitavus suur saavutus. 

Kui meil oli piisavalt muudatusi, andsime välja uue süsteeminõuete dokumendi ja uue alamsüsteemi nõuete dokumendi. Need vaesed töövõtjad pidid läbima tohutud allsüsteeminõuded ja käsitsi määrama, mis on muutunud. Ma ei kujuta ette, kui kaua töövõtjad kulutasid selleks, et välja selgitada, milliste muudatuste pärast nad peaksid muretsema.

Just selle uuendusprojekti keskel ütles klient piisavalt ja andis minu meeskonnale ülesandeks hinnata ja valida nõuete haldustööriist. Meie valitud tööriist ei ole selle konkreetse arutelu jaoks oluline, kuid oluline on see, mida me selle tööriista valikust ja rakendamisest õppisime. Siin on mõned õppetunnid.

(1) – Pole ühtegi tööriista, mis kõigile meeldiks. Meil oli kasutajaid, kellele meie valik meeldis, ja neid, kes võitlesid meiega igal sammul. Ilma muudatust toetava ja jõustava kliendita poleks see sellise suure programmi puhul võimalik. Üks kasutaja kaebas tööriistaga loodud jälgitavusmaatriksi veeru suuruse üle, ignoreerides täielikult tõsiasja, et see säästis talle päevi käsitsi tehtud pingutustest.

(2) – Meie käsitsi jälgitavus ei olnud väga puhas. Kui me kogu oma teabe tööriista importisime ja selle linkisime, leidsime jälgitavuses palju lünki. Häirivam oli see, et meil olid lingid, millel polnud tegelikult mingit mõtet. Pidime oma jälgitavuse maatriksite puhastamiseks tegema palju tööd.

(3) - Lihtsalt jälgimisnõuete järgimine oli suurepärane, kuid nüüd saime kasutada sama jõupingutust nõuete sidumiseks katseplaanidega ja jõudsime nii kaugele, et sidusime allsüsteemi nõuded projekteerimisdokumentidega, mida saaksime üle vaadata. See ei juhtunud üleöö, aga siiski juhtus. Lõpuks saaksime jälgida süsteeminõudeid alates alamsüsteemi nõudest kuni projekteerimisdokumendini kuni koodimoodulini. Kasutasime isegi tööriista koodimoodulite keerukuse määramiseks ja kasutasime seda selleks, et määrata kindlaks, kui keeruline oleks muudatust rakendada ja testida.

(4) – Nõuete tööriista mõõdikud on testimistoimingute täielikkuse mõistmiseks võtmetähtsusega. Tihti arvasime, et oleme testimisega 50% valmis. 50% testidest sai ju täidetud. Siiski leidsime, et olime altid kõigepealt testima süsteemi lihtsamaid ja paremini mõistetavaid osi. Ehkki me olime 50% valmis, oli kõik allesjäänud väga kõrge riskiga. Õppisime oma testimist tähtsuse järjekorda seadma, vaadates nõuete prioriteete ja tarkvara keerukust – teavet, mida me ei saanud käsitsi jälgitavuse abil kindlaks teha.

(5) – Väga kerge oli üle jõu käia. Alusta lihtsast. Pidime oma ambitsioonikatest ideedest loobuma ja alustama lihtsa jälgitavuse mudeliga. Kui õppisime ja omandasime tööriistaga rohkem kogemusi, lisasime oma mudelisse rohkem teavet. Hindasime pidevalt oma protsessi, et välja selgitada, mida veel saaksime selle paremaks muutmiseks teha.

(6) - Ärge koonerdage koolituse ja juhendamisega. Koolitasime kõiki projektiga seoses ja lõime eksperdid, kes aitasid kasutajatel esialgsetest takistustest üle saada. Saatsime nädalateks oma eksperdid töövõtjate juurde, et aidata neil tööriista kasutamisega kursis olla. Meil oli isegi oma sisemine kasutajate rühm. Olge selliseks pingutuseks valmis.

Milline suurepärane õppimiskogemus see minu jaoks oli. Kui olete huvitatud sellisest muudatusest, et oma nõudeid parandada, võtke ühendust Visure Solutionsiga. Arutame teiega hea meelega teie protsessi.

Ärge unustage seda postitust jagada!