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.

 

 

 

---