4. 2-ma'ruza. Talablarning spetsifikatsiyasi. Talablarni tekshirish. Talablar o'zgarishi. Reja

4.2-ma'ruza. Talablarning spetsifikatsiyasi. Talablarni tekshirish. Talablar o'zgarishi.
REJA:
1. Talablarning spetsifikatsiyasi.
2. Talablarni tekshirish.
3. Talablar o`zgarishi.

1. Talablarning spetsifikatsiyasi.
Talablar spetsifikatsiyasi (eng. software requirements specification, SRS) - bu tizimning sifatiga oid barcha manfaatdor tomonlarning kutishlarini to'liq qamrab oladigan, axborot tizimini amalga oshirish uchun noyob foydalanuvchi talablarining tartiblangan, tuzilgan ro'yxati.
Dasturiy ta'minot talablarining spetsifikatsiyasi (SRS) - bu dasturiy ta'minot va uning tashqi interfeyslari uchun tuzilgan talablar to'plami (funktsionallik, ishlash, dizayndagi cheklovlar va atributlar).
Spetsifikatsiya matnli hujjat sifatida yaratilishi mumkin. Bunday hujjat Karl Vigersning "Dasturiy ta'minot talablarini ishlab chiqish" kitobida tasvirlangan.
Dasturiy ta'minot talablarining spetsifikatsiyasining shablon strukturasi quyidagicha:
• Maqsad. (Goal)
• Kirish. (Introduction)
• Ta'riflar, qisqartmalar, atamalar. (Definitions, Abbreviations, Terms)
• Umumiy ma'lumot. (Overview)
• Funktsionallik. (Functionality)
• Umumiy tavsif. (General Description)
• Talablar. (Requirements)
• Qulaylik. (Usability- "qulaylik va foydalanishda qulaylik)
• Ishonchlilik. (Reliability)
• Xizmat qilish

Ammo hujjatni saqlash juda noqulay, chunki matn muharriri aniq talablarning o'zgarishini kuzatib borish uchun zarur funktsiyalarni ta'minlamaydi. Shuning uchun talablarni boshqarish uchun maxsus vositalardan foydalaniladi.

Foydalanuvchilarning hikoyalarini talablarga aylantirish. Foydalanuvchilar tarixi ushbu dastur foydalanuvchisi nuqtai nazaridan kelajakdagi tizimda qanday qilib ma'lum bir operatsiyani bajarish kerakligini aks ettiradi. Ilgari biz foydalanuvchi hikoyasini tizim sifati bo'yicha qanday tuzish kerakligi haqida suhbatlashdik (foydalanuvchi hikoyalaridan talablarga o'tishda sifat ko'rsatkichlariga havolani yo'qotmaslik muhim).
Ammo tarix shart emas yoki ularning kombinatsiyasi emas. Bu dasturiy ta'minotning kelajagi haqidagi mumkin bo'lgan qarashlardan biridir va hatto bitta fokus-guruh ishtirokchisida bunday fikrlar ko'p bo'lishi mumkin. Siz falon funktsiyani u yoki bu tarzda bajarilishi mumkinligini tez-tez eshitishingiz mumkin. Va hikoya muallifining o'zi variantlarning qaysi biri yaxshiroq ekanini aniq ayta olmaydi. Foydalanuvchilarning hikoyalari turli odamlar bilan suhbatlar asosida shakllanadigan vaziyat haqida nima deyishimiz mumkin?
Talab, biz aytganimizdek, tizim dizaynida foydalanishga yaroqli bo'lgan bir qator xususiyatlarga ega bo'lishi kerak.
Bir qator talablar xususiyati foydalanuvchi hikoyalaridan avtomatik ravishda olinadi (albatta, agar hikoyalarning o'zi yaxshi ishlab chiqilgan bo'lsa). Shunday qilib, hikoyalardan kelib chiqadigan talab deyarli har doim dolzarb bo'lib, talabga javob beradi va kuzatilishi mumkin, asosan qarama-qarshiliklardan xoli va boshqa talablar bilan bog'liq. Odatda, talabni qanday amalga oshirish va talab bajarilganidan keyin qanday qilib qondirilganligini qanday tekshirish haqida yuqori darajadagi tushunchalar mavjud.
Ammo biz atomlikni (to'liq bajariladigan yoki umuman bajarilmaydigan operatsiyani; qisman bajarilishi mumkin bo'lmagan va qisman bajarilmaydigan operatsiyani) va o'ziga xoslikni ta'minlashimiz, noaniqlikdan uzoqlashishimiz va har bir talabning to'liqligiga erishishimiz kerak. Shu bilan birga, izchillik va izchillikni yo'qotish mumkin emas. Shuningdek, talab haqiqatan ham amalga oshirilishi va sinovdan o'tkazilishi mumkinligiga ishonch hosil qilishingiz kerak.
Spetsifikatsiyadan foydalanishda talablarni boshqarish. Talablarni spetsifikatsiya shaklida tavsiflash muhim boshqaruv xususiyatlariga ega.
Birinchidan, spetsifikatsiyani o'zgartirish qiyin. Aslida bu yozilgan va kelishilganidan keyin jiddiy ravishda o'zgartirilishi mo'ljallanmagan. Siz kiritgan o'zgarish ta'sir qilishi mumkin bo'lgan bitta joyni o'tkazib yubormaslik uchun talablar ro'yxatining butun tuzilishini eslab qolishingiz kerak. Albatta, maxsus vositalardan foydalanish nazoratni osonlashtiradi, ammo muammoni hal qilmaydi. Shuning uchun spetsifikatsiya RUP-da qo'llaniladi, ammo Agile-da qo'llanilmaydi.
Ikkinchidan, spetsifikatsiyada ko'rsatilgan talablar yuzaki ishlab chiqilgan. Tizimga qo'yiladigan talablarni batafsil o'rganish texnik xususiyatlarni ishlab chiqish bosqichida va keyinchalik loyihalash paytida amalga oshiriladi deb taxmin qilinadi. Darhaqiqat, spetsifikatsiyadagi talablarni belgilashda biz kontseptsiyani ishlab chiqish bosqichida berilgan texnik-iqtisodiy baholardan ko'p chetlanmaymiz. Va bu, aslida, mas'uliyat va xatarlarni loyihadagi keyingi ish bosqichlariga o'tkazishni anglatadi. RUP uchun bu "faqat" so'nggi bosqichdagi xatolarni tuzatish narxini oshiradi. Ammo qisqa muddatli tsiklga ega bo'lgan tezkor metodikalar uchun bu yondashuv o'limga olib kelishi mumkin.
Uchinchidan, matn tavsifidan foydalanish juda noqulay. Agar matn katta bo'lsa, undagi kichik tafsilotlarni e'tiborsiz qoldirish oson, keyin xatolar tizimni amalga oshirishga kirib borishi mumkin, uni tuzatish qimmatga tushadi. 20 sahifadan ko'proq matnni o'qish ham tez ish emas.
Bundan tashqari, bitta odam matnli tavsiflarda o'ylamaydi - bu inson fiziologiyasiga ziddir. Biz tasvirlarda o'ylaymiz. Bizning ongimizda minglab harflar bo'lgan matn sahifasining tasviri hech qanday tarzda aniq vazifalar bilan bog'liq emas. Diagrammalar va grafikalar bilan ishlash ancha oson, shuning uchun spetsifikatsiyada iloji boricha ko'proq rasm bo'lishi kerak. Iloji bo'lsa, jadvallar va diagrammalar foydasiga qat'iy matndan voz kechishingiz kerak. Eng yomoni, siz ro'yxatlardan foydalanishingiz kerak.
Spetsifikatsiya qo'llaniladigan joyda. Spetsifikatsiyadagi asosiy muammo shundaki, talablar to'planib borishi bilan ularni boshqarish qiyinlashadi. Hatto juda oddiy talablarning o'zgarishi qanday boshqa talablarga ta'sir qilishini kuzatish juda qiyin. Natijada, yoki tahlilchi barcha talablar to'plamini "barmoq uchida ushlab turishi" kerak, yoki turli xil xatolar, qarama-qarshiliklar va nizolar talablarga singib keta boshlaydi.
Ba'zida spetsifikatsiya, agar tahlilchi uni 10 daqiqada o'qiy oladigan bo'lsa, amal qiladi, deyishadi - albatta hazil, lekin bu erda ba'zi bir sog'lom fikrlar mavjud.
Shunday qilib, spetsifikatsiya quyidagi hollarda amalda qo'llanilmaydi:
• epchil rivojlanish metodologiyasini qo'llash;
• talablarning ko'pligi;
• loyiha jamoasida ko'plab o'zaro ta'sirlarga ehtiyoj.
Bu erda jiddiy rezervasyon qilishimiz kerak. Tezkor metodologiyalardan, talablar tog'idan va ulkan jamoadan foydalanganda ham, masalan, loyiha guruhidan tashqarida bo'lgan manfaatdor tomonlar uchun talablar ro'yxatini taqdim etish uchun talab qilinishi mumkin: advokatlar, investorlar, mijoz uchun .. Ushbu odamlar kamdan-kam hollarda maxsus vositalardan foydalanadilar va ular uchun talablarning tavsifi bilan pdf hujjati etarli, ya'ni. loyiha jamoasi o'z faoliyatida foydalanadigan metodologiyadan qat'i nazar, texnik xususiyatlarning o'zi.
Shunday qilib, zamonaviy loyihadagi spetsifikatsiya hisobotning bir turi bo'lib, u bo'lishi mumkin yoki bo'lmasligi mumkin. Ammo ba'zi hollarda uni ishlatish qulay.