Talablar yigʻish va texnik topshiriq tuzilmasi: yaxshi talab qanday yoziladi

Dasturiy tizim qurishdagi eng qiyin qism nimani qurishni aniq hal qilishdir. Bu fikrni Frederick Brooks 1980-yillarning oʻrtasida yozgan va 1987 yilda IEEE Computer jurnalida «No Silver Bullet» nomli maqolasida eʼlon qilgan. Brooksning gapi shu kungacha oʻz kuchini yoʻqotmagan: avtomatlashtirish loyihasida koʻp bahslar texnologiyadan emas, talab yozilmagan yoki ikki tomon uni turlicha tushungan joydan chiqadi.

Mijoz nima xohlayotganini hamma vaqt bilmaydi

Brooks bu yerda ancha ochiq yozadi: mijozlar nima xohlashini bilmaydi, qanday savollarga javob berish kerakligini bilmaydi va muammoni talab yoziladigan darajadagi tafsilot bilan deyarli hech oʻylab koʻrmagan. «Yangi tizim eski qogʻoz tizimdek ishlasin» degan oddiy javob ham aslida juda sodda, chunki mijoz hech qachon aynan shuni xohlamaydi.

Gipotetik misol. Doʻkon egasi dasturchiga «hisobotlar Excelga oʻxshasin» deydi, dasturchi jadval chiqaradi, egasi esa aslida boshqa narsani oʻylagan edi: oxirgi qoldiq koʻrinadigan va bir bosishda yuklanadigan hisobot. Ikkalasi ham oʻz soʻzida haq, chunki talab yozilmagan.

Brooks yechimni ham aytadi: mijoz bilan loyihachi oʻrtasida koʻp martalik aylanma kerak. Talabni bir bor yozib qoʻyish yetmaydi, uni bosqichma-bosqich olish va aniqlashtirish dasturchining mijozga beradigan eng muhim xizmati. U yana bir narsani ham eʼtirof etadi: hatto dasturiy taʼminot muhandislari bilan ishlagan mijoz ham zamonaviy mahsulotning talabini toʻliq, aniq va toʻgʻri yoza olmaydi. Shuning uchun u tez namuna, yaʼni prototip yasab, odamlarga koʻrsatishni tavsiya qiladi.

Standart nima deydi: ISO/IEC/IEEE 29148

Talablar bilan ishlash qoidalari xalqaro standartda yozilgan. ISO/IEC/IEEE 29148 ning ikkinchi nashri 2018 yil noyabrda chiqqan. Standart ikki narsani belgilaydi: talablarni olish jarayonlari va ularning natijasi boʻladigan hujjatlar mazmuni.

Standartning kirish qismi uni shunday tushuntiradi: u talabni matn shaklida toʻgʻri tuzish qoidalarini, yaʼni talab belgilari va xususiyatlarini beradi. Hujjat loyiha hajmi, usuli va murakkabligidan qatʼi nazar qoʻllanishi mumkin deb yozilgan, yaʼni u katta davlat tizimi uchun ham, kichik kompaniyaning ichki dasturi uchun ham, hatto bir necha oylik ichki loyiha uchun ham mos keladi.

Standart talablarni bir qatlamda emas, bir necha hujjatda yuritadi. Uning mundarijasida toʻrtta hujjat turi bor: biznes talablari, manfaatdor tomonlar talablari, tizim talablari va dastur talablari. Tahririyat xulosasi: yuqori hujjat tizim nima uchun kerakligini, pastki hujjat esa aniq nima qilishini tushuntiradi, texnik topshiriq esa koʻpincha oxirgi ikkitasining oʻrnini bosadi.

Talabni kim aytishi ham muhim, shu sababli standart manfaatdor tomonlarni alohida mavzu sifatida koʻradi. Omborchi, buxgalter, savdo menejeri, rahbar va tizim egasi bir jarayonni turlicha koʻradi, shuning uchun bir kishining gapi butun korxona talabi emas. Har bir guruh bilan alohida gaplashib, soʻng umumiy jadvalga yigʻish talabdagi zidliklarni erta koʻrsatadi. Bu tahririyat mulohazasi.

Ehtiyojdan talabgacha: uch pogʻona

Standartning mundarijasida talablar bir zumda paydo boʻlmasligi koʻrinadi. Avval biznes yoki missiya tahlili, keyin manfaatdor tomonlar ehtiyoji va talablarini aniqlash, shundan keyingina tizim yoki dastur talablarini belgilash jarayoni keladi. Alohida bandda ehtiyojning talabga aylanishi tushuntirilgan, yaʼni talab xodimning shikoyatidan emas, uning ortidagi maqsaddan tugʻiladi.

Gipotetik misol. Omborchi «qoldiq notoʻgʻri chiqyapti» deydi. Bu hali talab emas, shikoyat. Uning ortida biznes ehtiyoji turadi: rahbar qaysi tovar tugayotganini oʻz vaqtida bilishi kerak. Shundan keyin tizim talabi yoziladi: har bir kirim va chiqim hujjati saqlanganda qoldiq yangilanadi va oxirgi yangilanish vaqti hisobotda koʻrinadi.

Uchta pogʻona boʻlsa, har bir talabdan orqaga qarab «bu nima uchun kerak?» deb soʻrash mumkin. Javob topilmasa, talab ortiqcha yoki tushunilmagan boʻlishi mumkin, javob topilsa esa talabning oʻrni ham, ahamiyati ham koʻrinadi. Bu usul talablarni qisqartiradi va keyinchalik qaysi biridan voz kechish mumkinligini koʻrsatadi.

Yaxshi talabning toʻqqiz belgisi

ISO 29148 alohida talab uchun toʻqqizta sifat belgisini beradi. Standartning oʻzi pullik, shuning uchun quyidagi tavsiflar ikkilamchi manbadagi jadvaldan olingan va oddiy tilda amaliy savol shaklida berilgan.

Tahririyat fikriga koʻra, amalda ikkita belgi koʻproq buziladi: bir maʼnolilik va tekshirib boʻladigan boʻlish. «Tez», «qulay», «zamonaviy» kabi soʻzlar ikkalasiga ham zid.

Jadvaldagi «yakka» belgisi koʻp loyihada eng oson buziladi. Bir jumlada «va» soʻzi uch marta uchrasa, bu odatda uchta talab bitta qatorga yigʻilganini bildiradi. Bunday talabni qabul qilish ham qiyin: ikkitasi bajarilib, bittasi bajarilmagan boʻlsa, qator bajarilgan hisoblanadimi yoki yoʻqmi, hech kim bilmaydi. Shu sabab uni boʻlib yozish, har bir qismga alohida tekshiruv qoʻyish maʼqul.

Talablar toʻplami ham tekshiriladi

Yakka talab yaxshi boʻlgani bilan toʻplam yaxshi boʻlmasligi mumkin, chunki ikki talab bir-biriga zid kelishi, muhim mavzu esa umuman yoritilmagan boʻlishi mumkin. Standartga tayanadigan bir sharhda toʻplam uchun beshta belgi sanalgan: toʻliqlik, bir-biriga zid emaslik, bajarilishi mumkinligi, tushunarliligi va manfaatdor tomon niyatiga qarab tekshirilishi. Bu manba sotuvchining oʻz maqolasi, shuning uchun uni yordamchi sifatida oʻqing.

Amaliy foydasi oddiy: topshiriqni yakunlashdan oldin hamma talabni bitta jadvalga yigʻib, bir-biriga zid yoki takror qatorlarni qidirish. Odatda ikki boʻlim bir narsani turlicha yozgan boʻladi, masalan savdo «chegirma buyurtma boʻyicha» deydi, moliya esa «chegirma mijoz boʻyicha». Bu mavzuni tizim emas, kelishuv hal qiladi.

Funksional talab va sifat talabi

Tizim nima qilishi bir narsa, uni qanchalik yaxshi qilishi esa boshqa narsa. Birinchisi funksional talab, ikkinchisi sifat talabi, va ikkinchisini unutish oson, chunki u kundalik gapda yashirinadi: «tizim tez ishlasin», «maʼlumot xavfsiz boʻlsin».

ISO/IEC 25010 standarti sifatni toʻqqiz xususiyatga boʻladi va bu modelni talabni aniqlash hamda uning toʻliqligini tekshirish uchun ishlatish mumkinligini aytadi. Model qabul mezonlarini topishga ham yordam beradi. Amalda bu bitta ishonchli roʻyxat boʻlib, har bir xususiyat boʻyicha oʻzimizdan «bu bizga muhimmi, muhim boʻlsa qanday chegarada?» deb soʻraymiz. Bu tahririyat usuli, standart uni shunday yozib bermaydi.

Texnik topshiriq tuzilmasi

ISO 29148 dastur talablari hujjati uchun namunaviy boʻlimlarni beradi. Quyidagi tuzilma shundan oddiy tilga oʻtkazilgan va kichik loyiha uchun qisqartirilgan, bu tahririyat moslamasi:

1. Maqsad va doira: nima uchun tizim kerak va nima unga kirmaydi.
2. Foydalanuvchilar: kim ishlatadi, qanday tayyorgarlik bilan.
3. Cheklovlar, taxminlar va bogʻliqliklar: nimaga tayanamiz va nimadan oldin ish bitmasligi mumkin.
4. Funksiyalar: tizim nima qiladi, har biri alohida talab sifatida.
5. Tashqi ulanishlar: boshqa tizimlar va qurilmalar bilan aloqa.
6. Tezlik, qulaylik va xavfsizlik talablari: oʻlchanadigan koʻrsatkichlar bilan.
7. Maʼlumotlarga talablar: qaysi maʼlumot saqlanadi va qancha muddat.
8. Qonun va standartlarga muvofiqlik.
9. Tekshirish usuli: har bir talab qanday qabul qilinadi.

Birinchi boʻlimda doiraga nima kirmasligini ham yozish foydali, bu ham tahririyat tavsiyasi. Standart andozasida cheklovlar, taxminlar va bogʻliqliklar alohida boʻlim sifatida berilgan. Masalan, «ombor hisobi kiradi, ishlab chiqarish rejasi esa birinchi bosqichga kirmaydi» degan bitta qator keyin oylar davomida kutilmagan talablar kelishini kamaytiradi.

Oxirgi boʻlim eng koʻp tashlab ketiladi. Standartning tizim va dastur talablari andozalarida tekshirish boʻlimi alohida turadi. Sabab oddiy: talab yonida uni qanday tekshirish yozilmasa, topshirish kuni har kim oʻz talqinini keltiradi.

Qabul mezoni misolini koʻrib chiqaylik, u ham gipotetik. Talab shunday yozilgan: qoldiq hisoboti 5000 qatorgacha 10 soniya ichida ochiladi. Qabul mezoni esa uning yoniga qoʻyiladi: sinov ish vaqtida, haqiqiy maʼlumotlar nusxasida, uch marta oʻlchanadi va eng yomon natija 10 soniyadan oshmasa, talab bajarilgan hisoblanadi. Shunday yozilsa, topshirish kuni «sekin ishlayapti» degan bahs oʻrniga bitta oʻlchov qoladi.

Talablar oʻzgaradi

Brooks talablarni bir marta toʻliq yozib qoʻyish mumkin deb hisoblamaydi. Standart ham oʻzgarishlarni boshqarishni va talablarning oʻlchanishini alohida boʻlim sifatida beradi. Demak, topshiriqning yagona nusxasi, versiyalari va kim oʻzgarishni tasdiqlashi oldindan kelishilishi kerak. Bu tahririyat xulosasi, ammo standartning tuzilmasi ham shunga ishora qiladi va oʻzgarishlar loyiha oxirida emas, boshidan rejalashtirilishini koʻrsatadi.

Amalda nima qilish mumkin

Quyidagi qadamlar manbalardan chiqarilgan tahririyat xulosasi, tayyor protokol emas.

1. Talabni yozishdan oldin kim ishlatishini va qaysi ishni oson qilishi kerakligini yozib oling.
2. Har bir talabni bitta jumlada, bitta fikr bilan yozing va yonida tekshirish usulini qoʻying.
3. «Tez», «qulay», «xavfsiz» kabi soʻzlarni raqam yoki aniq holat bilan almashtiring.
4. Eng muhim jarayon uchun tez namuna yasab, haqiqiy foydalanuvchiga koʻrsating.
5. Hamma talabni bir jadvalga yigʻib, bir-biriga zid va takror qatorlarni qidiring.

Kichik loyihada bu ishni bir odam bir kunda bajaradi, katta loyihada esa shu bir kun keyingi oylardagi bahsning katta qismini oldindan yopadi.