1-Mavzu: Dasturiy ta'minotga qo ’yilgan talablarni ishlab chiqish asoslari

1.3-rasm. Talablarni ishlab chiqishda turli manf aatdor tomonlarni jalb qilish misoli
Odamdan og'zaki ravishda uzatiladigan ma'lumotni emas, balki almashish uchun foydalanish mumkin 
bo'lgan shaklda hayotiy talablar yozma yozuvining qiymatini tushunish muhimdir. Bir vaqtlar men ishlab chiqish 
guruhlari tez-tez o'zgarib turadigan loyihada ishlaganman . Asosiy mijoz har bir yangi jamoa unga: "Biz talablar 
haqida gaplashishimiz kerak" degan so'zlar bilan kelganidan norozi edi. Uning bu iltimosiga munosabati 
quyidagicha edi: “Men avvalgilarimga mening talablarim haqida aytib berdim. Shunday qilib, tizimni qurishni 
boshlang! " Afsuski, hech kim talablarni hujjatlashtirishga qiynalmadi, shuning uchun har bir yangi
jamoa noldan boshlashi kerak edi . Hech bo'lmaganda, siz bir nechta elektron pochta xabarlari va ovozli pochta 
xabarlari, bir qator yopishqoq qaydlar, uchrashuv daqiqalari va mijozlarning suhbatlarining noaniq xotiralariga 
ega bo'lsangiz, "talabingiz bor" deb da'vo qilish mas'uliyatsizdir . Ushbu loyihaga talablar hujjatlari qanchalik 
to'liq bo'lishi kerakligini aniqlash uchun tahlilchi ehtiyotkorlik bilan yondashuvni ishlab chiqishi kerak.
Shaklda 1-1, uchta asosiy talab hujjatlari ko'rsatildi: tushuncha va chegara hujjati, foydalanuvchi talablari 
to'g'risidagi hujjat va dasturiy ta'minotga talablar spetsifikatsiyasi. Har bir loyihada ushbu uchta alohida hujjatni 
yaratish har doim ham shart emas. Ko'pincha bir ma'lumotni, ayniqsa kichik loyihalarda birlashtirish maqsadga 
muvofiqdir. Biroq, siz ushbu uchta hujjat turli xil ma'lumotlarni o'z ichiga olganligini, loyihaning turli 
bosqichlarida, ehtimol hatto turli maqsadlarga ega va turli maqsadli auditoriyaga ega bo'lgan turli odamlar 
tomonidan ishlab chiqilganligini tushunishingiz kerak .
Shakldagi model. 1-1 talablar to'g'risidagi ma'lumotlarning oddiy yuqoridan pastga qarab oqishini ko'rsatadi. 
Aslida, foydalanuvchi, funktsional va biznesga oid tsikllar va takroriyliklar bo'lishi mumkin. Har safar kimdir 
yangi xususiyatni, odatiy talabni yoki funktsionallikni yaxshilashni taklif qilganda, tahlilchi "Bu loyihaga mos 
keladimi?" Degan savolni berishi kerak. Agar javob ha bo'lsa, talab spetsifikatsiyada bo'lishi kerak. Aks holda, 
hech bo'lmaganda joriy versiyada yoki iteratsiyada hech qanday talab bo'lmasligi kerak. Uchinchi mumkin 
bo'lgan javob: "Yo'q, lekin u biznes maqsadini qo'llab-quvvatlaydi, shuning uchun u spetsifikatsiyada bo'lishi 
kerak." Bunday holda, loyiha doirasi uchun mas'ul shaxs - kurator, menejer yoki loyiha menejeri - yangi talabni 
kiritish uchun joriy loyihani yoki iteratsiyani kengaytirishni tanlash kerak. Bu loyiha jadvali va byudjetiga ta'sir 
qiladigan va boshqa imkoniyatlarni qurbon qilishni talab qiladigan biznes qarori. O'zgarishlarni boshqarishning 
samarali jarayoni, shu jumladan ta'sirni tahlil qilish, "to'g'ri odamlar" biznesni qaror qabul qilishini, ular 
o'zgarishi kerak bo'lgan vaqt yoki resurs xarajatlari yoki savdolar hisobga olinishini ta'minlaydi.

---