Nõuete haldamine
Nõuete haldamine on struktureeritud protsess toote, süsteemi või projekti nõuete kogumiseks, dokumenteerimiseks, valideerimiseks, prioriseerimiseks ja jälgimiseks kogu selle elutsükli jooksul.
Nõuete haldamine algab kogumisest: intervjuude, töötubade või otsese vaatluse kaudu selgitatakse välja, mida kliendid, kasutajad või sisemised huvirühmad tegelikult vajavad. Kui nõuded on kogutud, dokumenteeritakse need, kontrollitakse vastuolude suhtes ning jaotatakse funktsionaalseteks nõueteks, mida süsteem peab tegema, ja mittefunktsionaalseteks nõueteks, näiteks turvalisus, jõudlus või kasutatavus. Alles seejärel toimub prioriseerimine, sageli MoSCoW-meetodi abil, mis jaotab nõuded kohustuslikeks, soovitavateks, võimalikeks ja mittevajalikeks.
Dokumentatsioon hõlmab tavaliselt äriliste nõuete dokumenti, mis kirjeldab, mida klient soovib saavutada, ning sellele vastavat spetsifikatsiooni, mis kirjeldab, kuidas pakkuja kavatseb seda ellu viia. Nõuete jälgitavusmaatriks seob iga üksiku nõude selle allika, staatuse ja hilisemate testijuhtumitega, mis kinnitavad, et nõue täideti. Agiilsetes projektides võtab selle rolli sageli üle tootemahajäänud (product backlog), kus nõuded on kirjas kasutajalugudena, mida sprint sprindi haaval täpsustatakse ja ellu viiakse.
Kui nõuded muutuvad projekti käigus, käivitub korralik muudatuste haldusprotsess: iga muudatust hinnatakse, kaalutakse kulude ja ajakava suhtes ning võetakse vastu alles pärast ametlikku kinnitamist. Selle sammu vahele jätmine toob kaasa mahupuhangu (scope creep) ehk tarnitava sisu järkjärgulise laienemise ilma vastava eelarve või ajakava kohandamiseta. Korralik nõuete haldamine on see, mis üldse võimaldab realistlikke pakkumisi, selget vastutust ja kontrollitavaid tulemusi.
Praktiline näide
Keskmise suurusega pakendimasinate tootja plaanib uut tellimuste töötlemise tarkvara. Nõuete haldamise osana intervjueerib projektimeeskond 12 töötajat müügi-, tootmis- ja saatmisosakonnast ning kogub kokku 84 üksiknõuet. Pärast MoSCoW-meetodiga prioriseerimist jääb esimese väljalaske jaoks alles 31 kohustuslikku nõuet, mis on kirjas 18-leheküljelises nõuetedokumendis. Rakendamise poole peal muutub üks arvete koostamist puudutav nõue, ja muudatuste haldus dokumenteerib selle jälgitavusmaatriksis, et kõik osalised saaksid selle algsele nõudele tagasi viia.
Kuidas Leanshift aitab
Nõuete haldamine ja Kaizen jagavad sama alusseisukohta: enne millegi parandamist tuleb täpselt aru saada, mida tegelikult vaja on. Nõuete hoolikas kogumine ja järjekindel jälgimine tagab, et paranduspüüdlused tabavad tegelikku eesmärki, mitte ei jälita sümptomeid. See selgus on ise osa protsessitööst, see toob esile, mis tegelikult loeb, ja annab teistele kindla aluse edasiseks parandamiseks.
Korduma kippuvad küsimused
Mis vahe on nõuete haldamisel ja nõuetedokumendil, näiteks lähteülesandel?
Nõuete haldamine on käimasolev protsess, nõuetedokument on selle üks väljund. See kirjeldab, mida klient soovib saavutada, samas kui sellele vastav spetsifikatsioonidokument kirjeldab, kuidas pakkuja seda ellu viib.
Millal peaks nõuete haldamine projektis algama?
Ideaaljuhul kontseptsiooni- või pakkumisfaasis, enne projekti enda algust. Nõuete selgitamine alles pärast rakendamise algust toob kaasa kuluka ümbertegemise ja mahupuhangu ohu.
Kuidas toimib nõuete haldamine agiilsetes projektides, näiteks Scrumis?
See toimib iteratiivselt tootemahajäänu kaudu, mitte ühekordse dokumendina. Nõuded on kirjas kasutajalugudena, neid prioriseeritakse pidevalt ning täpsustatakse ja ellu viiakse sprint sprindi haaval.