2.8 Mahitaji ya programu

Muhtasari na msukumo

Hitaji la programu ni kauli ya uwezo au hali ambayo mfumo lazima itoe, itimize, au iwe nayo ili ikubalike kwa wadau wake. Uhandisi wa mahitaji, kazi yenye nidhamu ya kutoa, kuchambua, kubainisha, kuthibitisha, na kusimamia kauli hizo, iko mbele kabisa ya mnyororo wa thamani. Kila kitu kinachofuata, kutoka usanifu hadi msimbo hadi majaribio ya kukubalika, ni jaribio la kutimiza mahitaji. Kwa hiyo mahitaji yanapokuwa si sahihi, pungufu, au yenye utata, juhudi zote zilizotumika kujenga kitu kisicho sahihi kwa usahihi ni upotevu mtupu, na ndio upotevu ghali zaidi uliopo, kwa sababu unaugundua kuchelewa zaidi. Eneo la maarifa la Mahitaji ya Programu la Software Engineering Body of Knowledge (SWEBOK) linachukulia hili kama nidhamu halisi ya kihandisi, si utangulizi wa kikarani wa kazi halisi.

Kwa timu kubwa, mahitaji ni uelewa wa pamoja unaoruhusu watu wengi kujenga mfumo mmoja thabiti. Msanidi mmoja anaweza kushikilia nia kichwani; mamia ya watu kuvuka timu nyingi hawawezi. Mahitaji huwa mkataba kati ya wale wanaohitaji uwezo na wale wanaoujenga, msingi wa kugawanya kazi kuvuka timu, na kipimo cha kuhukumu lini kitu “kimekamilika.” Yanaunganishwa moja kwa moja na ugunduzi (sura ya 11.1), ambapo matatizo na fursa huibuka; na misingi ya UX (sura ya 5.1), ambapo unaelewa mahitaji ya watumiaji; na API na usanifu wa violesura (sura ya 2.3), ambapo wajibu wa violesura hufungwa; na usanifu na sifa za ubora (sura ya 3.1), ambapo mahitaji yasiyo ya kiutendaji huendesha muundo; na usimamizi wa mradi (sura ya 10.6), ambapo wigo, gharama, na ratiba hupangwa kuyazunguka.

Katika mazingira ya mashirika makubwa na ya serikali, mahitaji hubeba uzito wa kisheria, wa kimkataba, na wa usalama. Mfumo unaodhibitiwa lazima uonyeshe kwamba kila wajibu ulioamriwa (ufikivu, faragha, usalama, uhifadhi wa rekodi, udhibiti wa kifedha) umenaswa kama hitaji, kutekelezwa, na kuthibitishwa kwa ushahidi. Ununuzi wa serikali mara nyingi hujengwa kuzunguka ubainishaji wa mahitaji, na malipo, ukaguzi, na uthibitisho vyote vinategemea kufuatilia kila hitaji hadi ushahidi kwamba lilitimizwa. Hapa, mahitaji ni zaidi ya mazoea mazuri: ndio uti wa mgongo wa uwajibikaji.

Kanuni kuu

Hitaji linaeleza haja au kikwazo, si suluhisho; linasema nini na kwa nini, si jinsi.
Kila hitaji lazima liwe la lazima, lisilo na utata, linaloweza kuthibitishwa, linalowezekana, na linalofuatilika.
Mahitaji hugunduliwa na kujadiliwa na wadau, hayavumbuliwi peke yake.
Mahitaji yasiyo ya kiutendaji na vikwazo huumba usanifu kama vile utendaji unavyofanya.
Mahitaji hubadilika; simamia mabadiliko kwa makusudi badala ya kuyagandisha au kuyapuuza.
Ufuatiliaji, kutoka haja hadi hitaji hadi usanifu hadi jaribio hadi ushahidi, ni tishu ya kuunganisha ya uwajibikaji.
Kiwango sahihi cha urasmi kinategemea hatari, ukubwa, na muktadha wa udhibiti, si mazoea.

Mapendekezo

Fafanua mahitaji kwa uwazi na uyaainishe

Taja kategoria kwa makusudi. Mahitaji ya kiutendaji yanaeleza mfumo lazima ufanye nini: tabia, mabadiliko, na huduma unazotoa. Mahitaji yasiyo ya kiutendaji (sifa za ubora) yanaeleza lazima ufanye vizuri kiasi gani: utendaji, upatikanaji, usalama, uwezo wa kutumika, ufikivu, uwezo wa kudumishwa, na zaidi; haya yanafungamana kwa karibu na usanifu (sura ya 3.1). Vikwazo ni mipaka isiyojadiliwa juu ya suluhisho: teknolojia zilizoamriwa, viwango, bajeti, sheria, au violesura vya mifumo iliyopo. Na tenganisha mahitaji ya biashara (kwa nini shirika linataka mfumo) na mahitaji ya mtumiaji (watumiaji wanahitaji kukamilisha nini) na mahitaji ya mfumo (programu lazima ifanye nini kwa hiyo). Changanya ngazi hizi pamoja na mkanganyiko wa wigo hufuata hivi karibuni.

Toa kutoka vyanzo halisi, si dhana

Kutoa ni ugunduzi hai. Chota mahitaji kutoka kwa wadau kupitia usaili, warsha, uchunguzi, mifano ya majaribio, na uchambuzi wa mifumo na nyaraka zilizopo. Tafuta kila mdau husika, ikijumuisha wale rahisi kupuuza: waendeshaji, wakaguzi, wafanyakazi wa msaada, na watu walioathiriwa na mfumo ambao hawautumii moja kwa moja. Funga kutoa na bomba la ugunduzi (sura ya 11.1) na utafiti wa UX (sura ya 5.1), ili matakwa yaliyotajwa yafuatiliwe hadi mahitaji ya msingi. Rekodi chanzo na sababu ya kila hitaji, kwa sababu kujua kwa nini hitaji lipo ndiko kunakokuruhusu kulibadilisha kwa usalama baadaye.

Changanua, jadili, na upe kipaumbele

Mahitaji ghafi yaliyotolewa hugongana, huingiliana, na kujumlika kuwa zaidi ya yanayowezekana. Uchambuzi ndio jinsi unavyoyapatanisha: ainisha mahitaji, tambua migongano, pima uwezekano na hatari, na jadili vipaumbele na wadau. Pa kipaumbele wazi, kwa mfano kwa tofauti za lazima/inapaswa/inaweza au kupanga kwa thamani-dhidi-ya-gharama, ili muda unapopungua, ukate wigo sahihi. Na unda mifano ya mahitaji popote mfano unaongeza uwazi: mtiririko wa mchakato, michoro ya hali, mifano ya data, na fasili za violesura hufichua mapengo ambayo maandishi yanayaficha.

Bainisha kwa kiwango sahihi cha urasmi

Andika mahitaji kwa umbo linalofaa hatari na hadhira. Mfumo wa serikali wa uhakikisho wa juu unaweza kustahili ubainishaji rasmi uliopangwa kwa kiwango kama IEEE 29148; timu ya bidhaa yenye mwendo wa haraka inaweza kunasa mahitaji kama hadithi za mtumiaji zenye vigezo vya kukubalika kwenye backlog. Njia yoyote, kila hitaji linapaswa kuwa dogo kabisa, linaloweza kuthibitishwa, na lisilo na maneno ya kuteleza kama “haraka,” “rafiki kwa mtumiaji,” au “n.k.” Ambatisha vigezo vya kukubalika, ili ufafanue jinsi ya kuthibitisha hitaji wakati uleule unapoliandika. Na uweke chanzo kimoja chenye mamlaka, badala ya kuacha mahitaji yatawanyike kuvuka barua pepe, tiketi, na slaidi.

Thibitisha kabla ya kujenga

Uthibitisho unahakikisha mahitaji uliyobainisha ni sahihi na yanaungana. Yapitie na wadau, pitia mazingira, na pale unapoweza, tumia mifano ya majaribio kufanya kauli dhahania ziwe madhubuti. Uthibitisho ni nafuu kuliko marekebisho yoyote ya baadaye: kasoro iliyonaswa kwenye mapitio ya mahitaji inagharimu sehemu ndogo ya kasoro ileile iliyonaswa kwenye uzalishaji.

Simamia mahitaji na udumishe ufuatiliaji

Mahitaji hubadilika. Kazi yako ni kudhibiti mabadiliko hayo, si kuyapinga. Weka mchakato wa mabadiliko: pima kila badiliko linalopendekezwa kwa athari, gharama, na athari ya chini ya mkondo kabla ya kulikubali. Weka mahitaji kama vipimo vya msingi katika nukta zilizokubaliwa na uyaweke katika matoleo. Dumisha ufuatiliaji wa pande mbili unaounganisha kila hitaji mbele hadi usanifu, msimbo, na majaribio, na nyuma hadi haja iliyolitoa. Ufuatiliaji hujibu maswali mawili ambayo timu kubwa huishi kwayo: haja hii ikibadilika, inaathiri nini; na kwa kipengele hiki kilichotolewa, haja ipi ililihalalisha? Katika muktadha unaodhibitiwa, panua ufuatiliaji hadi ushahidi wa kukubalika (matokeo ya majaribio, rekodi za ukaguzi, saini) ili uweze kuonyesha uzingatiaji badala ya kudai tu.

Rekebisha kwa miktadha ya agile na inayoendeshwa na mpango

Katika programu zinazoendeshwa na mpango na zinazodhibitiwa, unabainisha na kuweka mahitaji kama vipimo vya msingi mapema kiasi, kwa udhibiti rasmi wa mabadiliko. Katika miktadha ya agile, mahitaji huishi kama backlog iliyopewa kipaumbele, inayobadilika, inayoelezwa kwa kina kabla tu ya utekelezaji na kuthibitishwa mfululizo kupitia programu inayofanya kazi. Shughuli za msingi ni zilezile katika zote mbili; muda, urasmi, na vitu tu ndivyo vinavyotofautiana. Mashirika makubwa mara nyingi huchanganya hizi mbili: hubainisha na kufuatilia wajibu thabiti wenye uhakikisho wa juu rasmi, huku yakielezea tabia ya bidhaa kwa kurudia. Chagua uwiano kwa hatari, si itikadi.

Mabadilishano: faida na hasara

Mbinu	Bora kwa	Faida	Hasara
Ubainishaji rasmi wa awali	Uhakikisho wa juu, unaodhibitiwa, mikataba ya wigo uliowekwa	Ufuatiliaji imara; msingi wazi wa kukubalika; unaokaguliwa	Polepole kubadilika; hatari ya kubainisha kupita kiasi kabla ya kujifunza
Backlog ya agile	Bidhaa zinazobadilika zenye wadau walioshiriki	Maoni ya haraka; hubadilika na kujifunza; upotevu mdogo kwa wigo ambao haujajengwa	Ufuatiliaji dhaifu wa muda mrefu; magumu zaidi kukagua na kuingia mkataba
Mseto (vikwazo rasmi + tabia ya agile)	Mashirika makubwa yenye wajibu mchanganyiko	Ukali pale unapojalisha, unyumbufu pengine	Inahitaji busara kuhusu sehemu zipi ni zipi

Mvutano mkuu ni kati ya uthabiti na kujifunza. Kuweka mahitaji mapema kunakununulia msingi imara wa kukubalika na uwezo wa kukaguliwa, lakini kunakugharimu uwezo wa kukabiliana na unachojifunza wakati wa kujenga. Kuyaahirisha kunakununulia unyumbufu, lakini kunakugharimu ufuatiliaji wa muda mrefu na uwazi wa kimkataba. Kuwekeza zaidi katika uhandisi wa mahitaji pia kunabadilishana kasi ya karibu na kurudia kazi kidogo baadaye: mabadilishano yanayolipa ukubwa, uimara, na matokeo ya kushindwa ya mfumo yanapopanda. Miradi mikubwa zaidi na inayodhibitiwa zaidi iko imara upande wa uwekezaji wa juu. Zana ya ndani yenye dau la chini haiko.

Maswali ya kujadili na timu yako

Nani anahesabiwa kuwa mdau kwa mfumo wetu wenye hatari ya juu zaidi, na ni wapi tunaendelea kuwaacha nje hadi kukubalika? Katika programu kubwa watu wanaoruka mara chache ni watumiaji dhahiri: ni waendeshaji wanaoendesha kitu saa tisa usiku, wakaguzi wanaopaswa kukithibitisha, wafanyakazi wa msaada wanaopokea kushindwa, na watu wasio watumiaji walioathiriwa ambao hawaingii kamwe lakini ambao data yao unaishikilia. Wakose na utagundua mahitaji yao wakati ghali zaidi, wakati wa kukubalika au mdhibiti anapouliza. Leta ramani madhubuti ya wadau kwenye mkutano na uipime: kwa kila wajibu ulioamriwa (ufikivu, faragha, uhifadhi wa rekodi, usalama) taja mtu anayeumiliki na hitaji linalouenasa. Usipoweza kutaja mmiliki, umepata pengo, na suluhisho ni kuongeza mdau huyo kwenye kutoa mahitaji sasa badala ya kuingiza mahitaji yake kwa urekebishaji kwenye usanifu uliowekwa baadaye.
Hitaji linapobadilika, tunaweza kujibu linaathiri nini kabla ya kuidhinisha badiliko? Hili ni jaribio la vitendo la kama ufuatiliaji wenu wa pande mbili ni halisi au wa mapambo. Katika mfumo mkubwa au unaodhibitiwa, badiliko moja la kanuni linaweza kuvuka hadi usanifu, msimbo, majaribio, na ushahidi wa kukubalika, na kuliidhinisha kwa upofu ndiko unakosafirisha mfumo unaoonekana unazingatia unaovunja kimyakimya kanuni iliyokuwa ikitimiza. Leta ombi la badiliko la hivi karibuni na ujaribu kulifuatilia mbele kwenye mkutano: ikichukua alasiri ya uchimbaji wa kiakiolojia, ufuatiliaji wenu haufanyi kazi yake. Jibu linapaswa kuumba upya mchakato wenu wa mabadiliko, ili tathmini ya athari iwe hoja ya haraka dhidi ya ufuatiliaji hai badala ya mawindo ya mkono, na ili vipimo vya msingi na matoleo vikupe nukta thabiti ya kubadilisha dhidi yake.
Chanzo kimoja chenye mamlaka cha mahitaji yetu kinaishi wapi, na ukweli kiasi gani umetawanyika nje yake? Kuenea kwa mahitaji (ubainishaji halisi ukiishi kuvuka barua pepe, tiketi, slaidi, na kumbukumbu ya mtu) ni mojawapo ya kushindwa kwa kawaida zaidi kwenye timu kubwa, na ni mauti kwenye mifumo inayokaguliwa ambapo lazima uonyeshe kilichokubaliwa. Amua, kwa sauti, mfumo gani wa rekodi ndio wa msingi, na uchukulie chochote kilichosemwa kwingineko kama rasimu hadi kitue hapo kikiwa na chanzo chake na sababu zimeambatishwa. Leta ushahidi: hesabu migogoro mingapi ya hivi karibuni ya wigo iliishia watu wawili wakitaja matoleo tofauti ya “mwisho.” Hesabu ikiwa kubwa kuliko sifuri, hatua ni kuunganisha kwenye chanzo kimoja na kuandika sababu ya kila hitaji, kwa sababu kujua kwa nini hitaji lipo ndiko kunakokuruhusu kulibadilisha au kuliacha kwa usalama baadaye.
Je, mahitaji yetu yasiyo ya kiutendaji yananaswa mapema vya kutosha kuendesha usanifu, au tunaendelea kuyagundua baada ya muundo kuwekwa? Wajibu wa utendaji, upatikanaji, usalama, na ufikivu huumba usanifu zaidi ya vipengele vingi, na katika programu kubwa ndiyo mahitaji yanayoibuliwa kuchelewa mara nyingi zaidi, muundo ambao ungepaswa kuyatimiza ukiwa umeshamiminwa saruji. Mvuto unaoshindana ni halisi: tabia ya kiutendaji ndiyo wadau wanaomba kwa sauti na kuonyesha vizuri, ilhali hitaji la “jibu la chini ya sekunde chini ya mzigo wa kilele” au “uzingatiaji wa ufikivu wa WCAG” halionekani hadi lavunjwe. Leta orodha ya sasa ya mahitaji yasiyo ya kiutendaji kwa mfumo wenu wenye hatari ya juu zaidi, nukta kwenye ratiba kila moja liliandikwa, na kama usanifu (sura ya 3.1) uliyapokea kama viendeshi wazi au kuyakisia. Katika mazingira ya mashirika makubwa na ya serikali, ongeza wajibu wa ubora ulioamriwa (usimbaji fiche, uhifadhi wa rekodi, sheria ya ufikivu) na uhakikishe kila moja ni hitaji lililoandikwa, linalopimika lililokabidhiwa kwa usanifu badala ya dhana, kwa sababu kurekebisha sifa ya ubora baada ya kukubalika ndiko bajeti na ratiba zinakufa kimya.
Kiwango sahihi cha urasmi kwa kila mfumo tunaomiliki ni kipi, na je, tunakichagua kwa hatari au kwa mazoea? Shirika kubwa moja kwa kawaida huendesha mgawanyo wa mifumo, kutoka zana ya ndani ya kutupwa hadi jukwaa linalodhibitiwa kwa usalama wa maisha, na kutumia taratibu zilezile kwa zote humzika kazi ya hatari ndogo katika karatasi au kuacha kazi ya hatari kubwa ikiwa haijabainishwa vya kutosha. Mvutano ni kati ya uwezo wa kukaguliwa na msingi imara wa kukubalika wa ubainishaji rasmi wa awali na maoni ya haraka na upotevu uliopungua wa backlog inayobadilika, na jibu la uaminifu kwa makampuni mengi ni mchanganyiko wa makusudi: rasimisha na ufuatilie wajibu thabiti wenye uhakikisho wa juu huku ukielezea tabia ya bidhaa kwa kurudia. Leta orodha fupi ya mifumo yenu iliyopangwa kwa matokeo ya kushindwa, mfiduo wa udhibiti, na kasi ya mabadiliko, na kwa kila moja taja urasmi mnaotumia dhidi ya urasmi ambao hatari inastahili. Kwa programu ya serikali iliyofungwa kwenye zabuni na kiwango kama IEEE 29148, urasmi kwa sehemu unaamriwa na mkataba, kwa hiyo mjadala ni mahali unaweza kuweka maelezo ya agile juu bila kuvunja ufuatiliaji ambao ukaguzi unautegemea.
Je, kila hitaji katika mfumo wetu wenye hatari ya juu zaidi linaweza kuthibitishwa, na je, kila moja lina vigezo vya kukubalika vilivyoandikwa wakati hitaji lilipoandikwa? Hitaji usiloweza kuthibitisha si hitaji, ni tamaa, na maneno ya kuteleza kama “haraka,” “salama,” au “rafiki kwa mtumiaji” hupita mapitio hasa kwa sababu hakuna anayeweza kuyashindwa. Kwa timu kubwa hili ni muhimu mara mbili: mahitaji yasiyoweza kuthibitishwa huzalisha migogoro ya wigo wakati wa kukubalika, na hufanya iwe haiwezekani kusema lini kipengele kimekamilika kweli. Jambo linaloshindana ni kasi, kwa kuwa kuambatisha kigezo kinachopimika na njia ya uthibitisho kwa kila hitaji ni polepole mapema kuliko kuandika maandishi, lakini ndiyo kinga ya bei nafuu zaidi dhidi ya kurudia kazi kwa kuchelewa kwa gharama kubwa zaidi. Leta sampuli ya mahitaji ya hivi karibuni na ujaribu kila moja dhidi ya kipimo rahisi: je, ni dogo kabisa, je, linapimika, na je, linataja litakaguliwaje. Katika miktadha inayodhibitiwa na ya serikali, panua jaribio hadi ushahidi: hitaji lisilo na ushahidi wa kukubalika unaofuatiliwa, unaopita halihesabiwi kuwa limetolewa bila kujali programu inaonekana kufanya nini, kwa hiyo vigezo vya kukubalika ni mbegu ya rekodi ya uzingatiaji ambayo hatimaye utalazimika kuizalisha.

Mtazamo wa sekta

Kampuni changa. Ukiwa na timu ndogo na muda mfupi wa fedha, weka mahitaji mepesi kadiri unavyoweza kuvumilia: hadithi za mtumiaji zenye vigezo vya kukubalika kwenye backlog moja ya pamoja, si waraka wa ubainishaji. Nidhamu inayolipa hata hapa ni kuzungumza na watumiaji halisi kabla ya kujenga na kurekodi chanzo na sababu ya kila hadithi, ili wiki ambayo ungepoteza kujenga kipengele kisicho sahihi iwe wiki unayookoa. Ruka ufuatiliaji rasmi, lakini kamwe usiruke mazungumzo yanayokuambia haja halisi ni nini.

Biashara ndogo. Huenda huna mchambuzi wa biashara au mtaalamu wa mahitaji, kwa hiyo kazi huangukia yeyote aliye karibu zaidi na mteja, na swali la kununua-dhidi-ya-kujenga hutawala. Weka mahitaji kama orodha fupi, iliyopewa kipaumbele ya matokeo unayoyahitaji, kisha uitumie kutathmini zana zilizotengenezwa tayari badala ya kubainisha ujenzi maalumu. Kuwa mkali kutenganisha haja ya msingi na orodha ya vipengele vya muuzaji, kwa sababu hitaji lililoandikwa kama “tunahitaji bidhaa X” linafunga kimyakimya chaguo za bei nafuu zaidi ambazo zingetimiza haja halisi.

Biashara kubwa. Ukubwa hugeuza mahitaji kuwa mkataba unaoruhusu timu nyingi kujenga mfumo mmoja thabiti, kwa hiyo kipaumbele ni mchakato wa kawaida unaotumika kwa uthabiti: kategoria zilizofafanuliwa, ufuatiliaji wa pande mbili kutoka haja hadi jaribio, chanzo kimoja chenye mamlaka, na mabadiliko yanayodhibitiwa yenye vipimo vya msingi. Tenganisha mahitaji ya biashara, mtumiaji, na mfumo waziwazi na ukabidhi mahitaji yasiyo ya kiutendaji kwa usanifu kama viendeshi, ili wigo na wajibu wa ubora visitawanyike kuvuka timu. Changanya ubainishaji rasmi kwa wajibu thabiti wenye uhakikisho wa juu na maelezo ya agile ya tabia ya bidhaa, na tawala uwiano kwa hatari badala ya upendeleo wa timu yoyote.

Serikali. Kanuni za ununuzi mara nyingi hujenga mkataba mzima kuzunguka ubainishaji wa mahitaji, mara nyingi ukipangwa kwa kiwango kama IEEE 29148, kwa hiyo usahihi na ukamilifu ni wa kimkataba, si wa hiari. Dumisha matriki ya ufuatiliaji wa mahitaji inayounganisha kila hitaji na usanifu, kesi za majaribio, na ushahidi wa kukubalika, kwa sababu malipo ya muuzaji, ukaguzi, na mamlaka ya kuendesha yote yanategemea ufikiaji ulioonyeshwa. Uwazi na uwajibikaji wa umma huinua kiwango zaidi: wajibu ulioamriwa wa ufikivu, faragha, na uhifadhi wa rekodi lazima kila moja uonekane kama hitaji wazi, linaloweza kuthibitishwa, na hitaji lisilo na ushahidi unaofuatiliwa, unaopita halijatolewa kabisa.

Mifano

Kampuni changa. Kampuni changa ya watu wanne inayojenga programu ya ratiba inanasa mahitaji kama hadithi za mtumiaji zenye vigezo vya kukubalika kwenye backlog ya pamoja, si ubainishaji rasmi. Kabla ya kuandika kipengele cha kusawazisha kalenda, mwanzilishi anatumia alasiri moja kuzungumza na wateja watarajiwa watano na anajifunza kwamba haja halisi ni kuepuka kuweka miadi mara mbili kuvuka zana mbili, si kusawazisha waliodhani. Mazungumzo hayo moja yanaweka upya hadithi na kuokoa wiki ya kujenga kitu kisicho sahihi. Hata kwa ukubwa huu wanaandika chanzo na sababu ya kila hadithi, kwa hiyo vipaumbele vinapohama wanaweza kuacha au kurekebisha wigo bila kubishana upya kwa nini ulikuwepo.

Biashara kubwa. Benki ya kimataifa inabadilisha jukwaa lake la kuanzisha mikopo. Timu ya mahitaji inatenganisha mahitaji ya biashara (punguza muda wa idhini, timiza kanuni za ukopeshaji), mahitaji ya mtumiaji (maafisa wa mikopo wanahitaji kulinganisha ofa katika mtazamo mmoja), na mahitaji ya mfumo (jukwaa lazima liungane na mifumo mitatu ya msingi). Mahitaji yasiyo ya kiutendaji (jibu la chini ya sekunde kwa hoja za kawaida, upatikanaji wa 99.95%, usimbaji fiche wa data binafsi) yananaswa waziwazi na kukabidhiwa kwa usanifu (sura ya 3.1) kama viendeshi. Kila hitaji linafuatiliwa kupitia backlog hadi majaribio ya kukubalika ya kiotomatiki. Kwa hiyo mdhibiti anapouliza kanuni mahususi ya ukopeshaji inatekelezwaje, timu inafuata tu njia kutoka kanuni hadi jaribio linalothibitisha.

Serikali. Wakala wa kitaifa unanunua mfumo wa kustahiki manufaa kupitia zabuni rasmi. Mkataba umefungwa kwenye ubainishaji wa mahitaji uliopangwa kwa IEEE 29148, ukifunika kanuni za kiutendaji za kustahiki, uzingatiaji ulioamriwa wa ufikivu, vikwazo vya faragha na uhifadhi wa rekodi, na udhibiti wa usalama. Matriki ya ufuatiliaji wa mahitaji inaunganisha kila hitaji na vipengele vya usanifu, kesi za majaribio, na ushahidi wa kukubalika. Malipo ya muuzaji na mamlaka ya kuendesha (idhini rasmi ya kuendesha mfumo katika uzalishaji) yote yanategemea ufikiaji ulioonyeshwa. Hitaji lisilo na ushahidi wa kukubalika unaofuatiliwa, unaopita halihesabiwi kuwa limetolewa, bila kujali programu inaonekana kufanya nini.

Kesi ya biashara: sababu, ROI, na TCO

Hoja ya kiuchumi ya uhandisi wa mahitaji inasimama juu ya gharama ya kurekebisha kasoro marehemu. Tafiti za tasnia mara kwa mara hugundua kwamba kasoro za mahitaji ni miongoni mwa sababu za kawaida na ghali zaidi za kushindwa kwa mradi, na kwamba gharama ya kurekebisha kasoro hupanda kwa vipimo vya ukubwa kutoka awamu ya mahitaji hadi uzalishaji. Kwa hiyo fedha zinazotumika kufafanua na kuthibitisha mahitaji kweli ni kiegemeo: uwekezaji wa kiasi mapema unakuokoa kujenga, kujaribu, na kuendesha kitu kisicho sahihi.

Jumla ya gharama ya umiliki wa mahitaji inajumuisha juhudi endelevu za kutoa, kubainisha, zana, na usimamizi wa mabadiliko kuvuka maisha yote ya mfumo; si gharama ya mara moja. Dhidi yake kuna gharama ya mahitaji duni: kurudia kazi, migogoro ya wigo, kuchelewa kwa ratiba, kukubalika kulikoshindwa, adhabu za kimkataba, na, katika mazingira yanayodhibitiwa, faini au kupoteza idhini. Kwa uongozi, weka ukomavu wa mahitaji kama kupunguza hatari na utabirika. Fuatilia tete ya mahitaji, asili ya kasoro, na sehemu ya kazi iliyotolewa inayofuatilika hadi haja iliyothibitishwa, na uyaunganishe na utabiri wa usimamizi wa mradi (sura ya 10.6). Mapato hayaonekani kama kipengele. Yanaonekana kama kushindwa na kurudia kazi ambavyo havikutokea kamwe.

Mifumo mibaya na mitego

Suluhisho zilizovikwa kama mahitaji: kubainisha teknolojia iliyochaguliwa au mpangilio wa skrini badala ya haja ya msingi, kufunga chaguo bora zaidi.
Lugha yenye utata: “haraka,” “salama,” “angavu” bila kigezo kinachopimika, kufanya hitaji lisilothibitishika.
Kupamba kupita kiasi: kunasa mahitaji ambayo hakuna mdau anayeyahitaji kweli, kuvimbisha wigo na gharama.
Mahitaji yasiyo ya kiutendaji yanayokosekana: kugundua wajibu wa utendaji, usalama, au ufikivu baada tu ya usanifu kuwekwa.
Kuenea kwa mahitaji: ukweli ukitawanyika kuvuka barua pepe, tiketi, na slaidi bila chanzo chenye mamlaka.
Mabadiliko yaliyogandishwa au yasiyodhibitiwa: ama kukataa mabadiliko yote au kukubali kila badiliko bila tathmini ya athari.
Hakuna ufuatiliaji: kushindwa kujibu badiliko linaathiri nini au kwa nini kipengele kipo, mauti katika mifumo inayokaguliwa.
Kupooza kwa uchambuzi: ubainishaji usioisha unaochelewesha kujifunza kutoka programu inayofanya kazi.
Wadau waliopuuzwa: waendeshaji, wakaguzi, na wasio watumiaji walioathiriwa wakiachwa nje hadi kukubalika.

Kielelezo cha ukomavu

Ngazi ya 1, Kuanzisha. Mahitaji ni ya kudokezwa au ya mdomo, yananaswa bila uthabiti na kwa kuitikia. Migogoro ya wigo na kurudia kazi ni ya kawaida; hakuna ufuatiliaji, hakuna vigezo vya kukubalika, na hakuna mchakato uliofafanuliwa.
Ngazi ya 2, Kuendeleza. Baadhi ya timu huandika mahitaji na kuyafuatilia kwa kila mradi, kwa kipaumbele cha msingi na ushughulikiaji wa mabadiliko wa papo hapo. Mazoea yapo lakini yanatofautiana kwa timu na mtu, kwa hiyo kategoria, urasmi, na ubora havina uthabiti kuvuka shirika.
Ngazi ya 3, Kusawazisha. Mchakato wa kawaida wa mahitaji umeandikwa na kutekelezwa shirika zima: kategoria zilizofafanuliwa, mazoea ya kutoa na kuthibitisha, vigezo vya kukubalika vilivyoambatishwa wakati wa kuandika, chanzo kimoja chenye mamlaka, na ufuatiliaji wa pande mbili kutoka haja hadi jaribio, uliorekebishwa kwa uthabiti kwa muktadha wa agile au unaoendeshwa na mpango.
Ngazi ya 4, Kusimamia. Mchakato unapimwa na kudhibitiwa kwa data. Tete ya mahitaji, asili ya kasoro, ufikiaji wa ufuatiliaji, na sehemu ya kazi iliyotolewa inayofuatilika hadi haja iliyothibitishwa vinafuatiliwa dhidi ya vipimo vya msingi; ufuatiliaji unapanuka hadi ushahidi wa kukubalika na uzingatiaji; na vipimo vya mahitaji vinalisha utabiri wa mradi (sura ya 10.6), kwa hiyo maamuzi ya mabadiliko na ubora yanasimama kwenye ushahidi badala ya maoni.
Ngazi ya 5, Kuratibu. Mazoea ya mahitaji yanaboreshwa kila wakati na kuunganishwa kuvuka shirika. Urasmi unarekebishwa kwa hatari na matokeo, zana za kutoa na kufuatilia zinaungana na ugunduzi, usanifu, na utoaji, na shirika linatumia historia yake ya upimaji kuzuia kasoro zinazorudiwa za mahitaji kabla hazijafika msimbo.

Mawazo ya kujadili

Unatofautishaje hitaji la kweli na suluhisho la mapema mdau mkuu anapolitaja kama suluhisho?
Kiwango sahihi cha urasmi wa mahitaji kwa mfumo wenu wenye hatari ya juu zaidi dhidi ya wa chini zaidi ni kipi, na nani anaamua?
Unaweka vipi ufuatiliaji wa pande mbili wa sasa katika backlog ya agile yenye mwendo wa haraka bila kuwa mzigo wa urasimu?
Ni mahitaji yapi yasiyo ya kiutendaji yanagunduliwa kuchelewa zaidi katika shirika lenu, na kwa nini?
Katika programu inayodhibitiwa, nini kinahesabiwa kuwa ushahidi wa kutosha wa kukubalika kwamba hitaji lilitimizwa?
Zana za kutoa na kubainisha zinazosaidiwa na AI zinapaswa kubadilishaje mazoea yenu ya mahitaji, na zinaleta hatari gani mpya?

Mambo muhimu ya kukumbuka

Mahitaji yanaeleza haja na vikwazo, si suluhisho; lazima yawe ya lazima, yasiyo na utata, yanayoweza kuthibitishwa, na yanayofuatilika.
Tenganisha mahitaji ya kiutendaji, yasiyo ya kiutendaji, na vikwazo, na ngazi za biashara, mtumiaji, na mfumo.
Toa kutoka kwa wadau halisi, changanua na upe kipaumbele, bainisha kwa urasmi unaofaa, thibitisha kabla ya kujenga, na simamia mabadiliko.
Ufuatiliaji wa pande mbili kutoka haja hadi ushahidi wa kukubalika ndio uti wa mgongo wa uwajibikaji, hasa katika mazingira yanayodhibitiwa.
Miktadha ya agile na inayoendeshwa na mpango inashiriki shughuli zilezile; hutofautiana kwa muda, urasmi, na vitu, kwa hiyo chagua kwa hatari.
Gharama ya mahitaji duni hulipwa marehemu na kuzidishwa; kuwekeza mapema ni kiegemeo dhidi ya kurudia kazi na kukubalika kulikoshindwa.

Marejeo na usomaji zaidi

IEEE and ISO/IEC, Guide to the Software Engineering Body of Knowledge (SWEBOK), Software Requirements knowledge area
Karl Wiegers and Joy Beatty, Software Requirements
ISO/IEC/IEEE 29148, Systems and software engineering: Life cycle processes: Requirements engineering
Suzanne Robertson and James Robertson, Mastering the Requirements Process
Dean Leffingwell, Agile Software Requirements
Mike Cohn, User Stories Applied
Ian Sommerville, Software Engineering (requirements engineering chapters)