PM 4: Talablar va texnik topshiriq — BRD, PRD, SRS, TZ

📋 IT Project Management

PM 4: Talablar va texnik topshiriq — BRD, PRD, SRS, TZ

Holat: 2026-yil sentabr. Dasturiy ta'minotdagi xatolarning 50% dan ortig'i kod yozishda emas, balki talablarni noto'g'ri tushunish va chala yozilgan texnik topshiriq (TZ) tufayli yuzaga keladi. Ushbu darsda xalqaro standartlar (ISO/IEC/IEEE 29148, ISO/IEC 25010), O'zbekiston va MDH amaliyotidagi GOST 34.602-2020 qoidalari, User Story va INVEST tamoyili, hamda App Store tekshiruvidan muammosiz o'tadigan real mobil ilova TZ shabloni tahlil qilinadi.

Mundarija

1. Hujjatlar ierarxiyasi: BRD, PRD, SRS va TZ
2. ISO/IEC/IEEE 29148 xalqaro standarti
3. GOST va O'zbekistonda TZ yozish amaliyoti
4. User Story va INVEST tamoyili
5. Gherkin sintaksisi: BDD va qabul mezonlari
6. Nofunksional talablar (NFR) va ISO/IEC 25010
7. Talablar izlanuvchanligi (RTM)
8. Mobil ilova uchun to'liq TZ namunasi
9. TZ'dagi eng katta xatolar
10. Change Request (O'zgarishlarni boshqarish)
11. Xulosa
12. Manbalar

1. Hujjatlar ierarxiyasi: BRD, PRD, SRS va TZ {#hujjatlar}

Har bir hujjat o'z auditoriyasi va maqsadiga ega (AltexSoft, ProductPlan, Wikipedia):

Agile jamoalarda ko'pincha PRD va User Story'lar yetarli bo'lsa, korporativ sektor va davlat buyurtmalarida yuridik jihatdan rasmiy TZ talab qilinadi.

2. ISO/IEC/IEEE 29148 xalqaro standarti {#standart}

Tarixan dasturiy talablar uchun IEEE 830 standarti (1984-yilda qabul qilingan, 1998-yilda yangilangan) ishlatilgan. 2011-yilda u bekor qilinib, o'rniga ISO/IEC/IEEE 29148 joriy etildi (amaldagi tahriri 2018-yil) (Wikipedia).

ISO 29148 talablar ierarxiyasini 4 qatlamga bo'ladi:

1. BRS (Business Requirements Specification): Tashkilotning strategik maqsadlari.
2. StRS (Stakeholder Requirements Specification): Foydalanuvchilar va manfaatdor tomonlar ehtiyojlari.
3. SyRS (System Requirements Specification): Tizim darajasidagi talablar (apparat + dasturiy).
4. SRS (Software Requirements Specification): Dasturiy ta'minotning o'ziga qo'yiladigan talablar.

Yaxshi talabning 8 ta sifati (ISO 29148):

• Unambiguous (Bir ma'noli): Faqat bitta talqin qilinishi mumkin.
• Verifiable / Testable (Tekshiriluvchan): Qabul qilish testi orqali tekshirish imkoni bo'lishi shart.
• Necessary (Zaruriy): Mahsulot maqsadi uchun haqiqatan kerak.
• Feasible (Amalga oshirib bo'ladigan): Mavjud texnologiya, byudjet va vaqt doirasida bajarish mumkin.
• Singular (Yagona): Bitta jumlada faqat bitta talab ifodalanadi ("va", "shuningdek" bilan bir nechta talab qorishtirilmaydi).
• Complete (To'liq): Barcha shartlar va cheklovlar ko'rsatilgan.
• Consistent (Ziddiyatsiz): Boshqa talablar bilan to'qnashmaydi.
• Traceable (Kuzatiluvchan): Biznes maqsaddan kod va testgacha bog'langan (ID mavjud).

3. GOST va O'zbekistonda TZ yozish amaliyoti {#gost}

O'zbekiston, Qozog'iston va boshqa MDH davlatlarida (EASC doirasida) yirik loyihalar va davlat xaridlarida GOST tizimi qo'llaniladi (Wikipedia).

Muhim huquqiy o'zgarish:

• O'nlab yillar davomida qo'llanilgan eski GOST 34.602-89 standarti o'z kuchini yo'qotgan.
• Uning o'rniga GOST 34.602-2020 standarti 2022-yil 1-yanvardan boshlab kuchga kirgan (GostExpert).
• Eslatma: Amaliyotda ko'plab davlat idoralari va kompaniyalar hali ham inersiya bilan eski -89 shablonlaridan foydalanishadi. PM buni bilishi va kerak bo'lganda buyurtmachiga yangilangan standart talablarini tushuntira olishi kerak. Dasturiy vositalar uchun esa qo'shimcha ravishda GOST 19.201-78 mavjud. O'zbekiston milliy O'zDSt standarti raqamlari barcha sohalar uchun yagona emas, shuning uchun shartnomada aniq havola qilinadigan GOST hujjati nomi ko'rsatiladi.

4. User Story va INVEST tamoyili {#user-story}

Agile loyihalarda talablar foydalanuvchi nigohi bilan ifodalanadi:

Shablon: Kim sifatida: [foydalanuvchi roli] Men xohlayman: [funksiya / harakat] Chunki / Maqsadim: [olinadigan biznes yoki shaxsiy foyda]

INVEST tamoyili

Bill Wake (2003-yil 17-avgust) tomonidan taklif qilingan va Mike Cohn (2004) tomonidan ommalashtirilgan qoidalar to'plami (XP123, Agile Alliance):

• I — Independent (Mustaqil): Boshqa story'lar bilan parallel bajarilishi mumkin.
• N — Negotiable (Muhokama qilinadigan): Qat'iy shartnoma emas, jamoa bilan o'zgarishi mumkin bo'lgan taklif.
• V — Valuable (Qadrli): Mijoz yoki biznes uchun aniq foyda keltiradi.
• E — Estimable (Baholab bo'ladigan): Dasturchilar uning ko'lamini chamalay oladi.
• S — Small (Kichik): Bitta sprint ichida (odatda 2–4 kunda) to'liq tugatish mumkin.
• T — Testable (Sinovdan o'tuvchan): Qabul mezonlari (Acceptance Criteria) aniq.

5. Gherkin sintaksisi: BDD va qabul mezonlari {#gherkin}

Har bir User Story aniq sinov ssenariylariga ega bo'lishi kerak. BDD (Behavior-Driven Development) amaliyotida buning uchun Gherkin sintaksisi qo'llaniladi (Cucumber Reference):

Feature: iOS ilovasida Apple Pay orqali obunani rasmiylashtirish

  Scenario: Foydalanuvchi birinchi marta oylik Pro obunani xarid qiladi
    Given foydalanuvchi hisobiga kirgan va bepul tarifda
    And uning qurilmasida Apple Pay sozlangan
    When u "Pro obunani faollashtirish" tugmasini bosadi
    And Face ID orqali to'lovni tasdiqlaydi
    Then StoreKit tranzaksiyasi muvaffaqiyatli yakunlanishi kerak
    And foydalanuvchi hisobi darhol "Pro" maqomiga o'tishi kerak
    And ekranda "Tabriklaymiz, Pro faollashtirildi" xabari chiqishi kerak

  Scenario Outline: Promo-kod kiritilganda chegirma hisoblash
    Given foydalanuvchi to'lov ekranida
    When u promo-kod maydoniga "<kod>" kiritadi
    Then yakuniy summa "<summa>" bo'lishi kerak

    Examples:
      | kod      | summa     |
      | START20  | 80 000    |
      | SPRING50 | 50 000    |
      | INVALID  | 100 000   |

6. Nofunksional talablar (NFR) va ISO/IEC 25010 {#nfr}

Ilova nima qilishi — bu funktsional talab (FR). Qanchalik tez, xavfsiz va ishonchli ishlashi esa — Nofunksional talab (NFR).

ISO/IEC 25010 sifat modeli 7 ta asosiy tasdiqlangan xarakteristikani belgilaydi (ISO 25000):

1. Functional Suitability: Funktsional to'liqlik va to'g'rilik.
2. Performance Efficiency: Vaqt va resurs samaradorligi (javob berish tezligi, CPU/xotira yuki).
3. Compatibility: Boshqa tizimlar bilan moslik (iOS versiyalari, ekran o'lchamlari).
4. Interaction Capability / Usability: Qulaylik, estetik interfeys va a11y (WCAG 2.2 tavsiyasi, 2023-yil 5-oktabr, tahrir 2024-yil 12-dekabr) (W3C WCAG).
5. Reliability: Ishonchlilik, xatolarga chidamlilik va qayta tiklanish.
6. Security: Autentifikatsiya, shifrlash va ma'lumotlar yaxlitligi.
7. Maintainability: Kodning o'zgaruvchanligi, modulliligi va testga qulayligi.

Yomon va o'lchanadigan NFR taqqoslashi:

7. Talablar izlanuvchanligi (RTM) {#moscow-rtm}

RTM (Requirements Traceability Matrix) — har bir biznes talab qaysi texnik talabga, qaysi kod moduliga va qaysi test keysiga bog'langanini ko'rsatuvchi matritsa (ReqTest):

• Forward Traceability: Biznes talabdan kod va testgacha (hech narsa esdan chiqmaganmi?).
• Backward Traceability: Test va koddan biznes talabga (talabda yo'q ortiqcha narsa yozilmadimi?).
• Bidirectional Traceability: Ikki tomonlama to'liq nazorat.

8. Mobil ilova uchun to'liq TZ namunasi {#tz-namuna}

Quyida iOS va Backend loyihasi uchun shartnoma ilovasi bo'ladigan professional TZ tuzilmasi keltirilgan:

================================================================================
TEXNIK TOPSHIRIQ: "ShopMaster" iOS Mobil Ilovasi va Backend v1.0
================================================================================

1. UMUMIY MA'LUMOTLAR
   1.1. Loyiha nomi: ShopMaster iOS elektron tijorat ilovasi.
   1.2. Buyurtmachi: "Retail Hub" MCHJ.
   1.3. Ijrochi: "Mobile Engineering" MCHJ.
   1.4. Muddat: 2026-yil 1-oktabrdan 2026-yil 15-dekabrgacha.

2. LOYIHA MAQSADI VA MUVAFFAQIYAT MEZONLARI
   2.1. Maqsad: Mijozlarga iOS orqali to'g'ridan-to'g'ri xarid qilish imkonini berish.
   2.2. KPI: Qabul qilinganidan so'ng 30 kun ichida Crash-free users >= 99.5%.

3. LOYIHA KO'LAMI (SCOPE)
   3.1. Ko'lamga kiradi (In-Scope):
        - iOS ilova (iOS 17, 18, 26 versiyalari uchun SwiftUI arxitekturasi);
        - REST API backend (Node.js/Express, PostgreSQL);
        - Web Admin panel (buyurtmalarni boshqarish);
        - To'lov tizimlari (Apple Pay va Payme/Click integratsiyasi).
   3.2. Ko'lamga kirmaydi (Out-of-Scope):
        - Android ilova (alohida faza);
        - Sodiqlik dasturi va keshbek tizimi (v2.0 da rejalashtirilgan);
        - Foydalanuvchilar o'rtasida chat funksiyasi.

4. FOYDALANUVCHI ROLLARI VA HUQUQLAR MATRITSASI
   4.1. Mehmon (Guest): Katalog ko'rish, savatga qo'shish.
   4.2. Xaridor (Customer): Buyurtma berish, to'lov qilish, profil boshqarish.
   4.3. Admin: Mahsulot qo'shish, buyurtma statusini o'zgartirish.

5. FUNKSIONAL TALABLAR (MODULLAR BO'YICHA)
   [FR-AUTH-01]: Telefon raqam va SMS-kod orqali kirish.
   [FR-AUTH-02]: Sign in with Apple orqali kirish (App Store 4.8-band talabi).
   [FR-CAT-01]: Kategoriyalar va mahsulotlar ro'yxatini filtrlash.
   [FR-CART-01]: Mahsulotni savatga qo'shish va mahalliy keshda saqlash.
   [FR-PAY-01]: Apple Pay orqali bir bosishda to'lov qilish.

6. NOFUNKSIONAL TALABLAR (NFR)
   6.1. Unumdorlik: Sovuq ishga tushish (Cold start) iPhone 13 va undan yangi
        modellarida 1.5 soniyadan oshmasligi kerak.
   6.2. Xavfsizlik: Barcha API so'rovlari HTTPS (TLS 1.3) orqali yuboriladi.
   6.3. Dizayn: Figma faylida ko'rsatilgan Auto Layout va ranglar tizimiga
        100% mos kelishi shart.

7. APP STORE CONNECT VA APPLE TALABLARI
   7.1. App Store Guideline 2.1: Apple tekshiruvchisi uchun doimiy ishlaydigan
        demo akkaunt taqdim etilishi shart (login: demo@shopmaster.uz / sms: 7777).
   7.2. Guideline 3.1.2: Obuna sotilsa, muddat kamida 7 kunlik bo'lishi va
        barcha narxlar ekranda aniq ko'rsatilishi shart.
   7.3. Guideline 4.8: Uchinchi tomon ijtimoiy tarmoqlari bilan kirish bo'lsa,
        ekvivalent "Sign in with Apple" varianti bo'lishi majburiy.
   7.4. Guideline 5.1.1: Maxfiylik siyosati (Privacy Policy) sahifasi havolasi
        ro'yxatdan o'tish ekranida va App Store Connect metadata'sida ko'rsatiladi.
   7.5. Privacy Manifest: 2024-yil 1-maydan boshlab talab qilinadigan
        PrivacyInfo.xcprivacy fayli to'liq kiritiladi (qarang: /ios-lessons/devops-cicd#privacy-manifest).
   (Apple qo'llanmasi doimiy yangilanuvchi tirik hujjat hisoblanadi).

8. TOPSHIRILADIGAN ARTEFAKTLAR VA QABUL QILISH TARTIBI
   8.1. GitHub repository (to'liq kod bazasi va CI/CD pipeline).
   8.2. Figma manba fayllari.
   8.3. Swagger/OpenAPI formatidagi backend API hujjatlari.
   8.4. TestFlight orqali sinov uchun yuborilgan Release Build.
   8.5. Qabul qilish: 5 ish kuni ichida dalolatnoma imzolanadi yoki yozma
        e'tiroz bildiriladi.
================================================================================

9. TZ'dagi eng katta xatolar {#xatolar}

Tajribasiz loyihalarda ko'p uchraydigan tuzoqlar:

1. Noaniq sifat so'zlari: "Ilova chiroyli, intuitiv va tez bo'lishi kerak". Har bir talab metrika bilan yozilishi shart.
2. "Va hokazo..." (va h.k.) ro'yxatlar: "To'lovlar: Payme, Click va hokazo". Dasturchi faqat 2 tasini qiladi, buyurtmachi esa 10 tasini kutadi. Ro'yxat doimo yopiq bo'lishi kerak.
3. Out-of-Scope (Ko'lamdan tashqari) qismi yo'qligi: Nimani qilmasligingizni yozmasangiz, buyurtmachi barcha xayoliga kelgan narsani shartnomaga kiradi deb o'ylaydi.
4. Qabul mezonlari (Acceptance Criteria) yo'qligi: Ish qachon bitgan deb hisoblanishi oldindan aniq bo'lmasa, topshirish oylab cho'ziladi.
5. Og'zaki kelishuvlar: Telegram yoki kofe ustida aytilgan o'zgarishlar TZ'ga rasmiy kiritilmasa, yuridik kuchga ega emas.

10. Change Request (O'zgarishlarni boshqarish) {#change-request}

Loyiha davomida talablar o'zgarishi tabiiy holat. Lekin har qanday o'zgarish rasmiy Change Request (CR) tartibi orqali amalga oshiriladi (Wikipedia):

+-------------------------------------------------------------------------------+
|                        CHANGE REQUEST (CR) SHABLONI                           |
+-------------------------------------------------------------------------------+
| CR ID: CR-014                                  Sana: 2026-10-15               |
| So'rovchi: Akmal (Product Owner)               PM: Azimjon                    |
+-------------------------------------------------------------------------------+
| Tavsif: Mahsulot kartasida yetkazib berish vaqtini ko'rsatuvchi vidjet qo'shish|
| Sabab: Foydalanuvchilar konversiyasini oshirish bo'yicha marketing talabi     |
| Ta'sirlangan talablar (RTM): [FR-CAT-01], [FR-CART-01]                        |
+-------------------------------------------------------------------------------+
| TA'SIRNI BAHOLASH:                                                            |
| - Scope: 1 ta yangi UI komponent, 1 ta yangi API endpoint                     |
| - Vaqt: +4 ish kuni                                                           |
| - Byudjet: +$600                                                              |
| - Xatar: Yandex Delivery API'ga bog'liqlik vujudga keladi                     |
+-------------------------------------------------------------------------------+
| QAROR: [X] Tasdiqlandi (Approved)   [ ] Rad etildi   [ ] Keyinga qoldirildi   |
| Tasdiqlovchi: B. Aliyev (Boshqaruvchi)         Imzo: ___________              |
| Yangi TZ versiyasi: v1.2                                                      |
+-------------------------------------------------------------------------------+

O'zgarishlarni boshqarishning 6 qadami:

1. Qayd etish: So'rov yozma ravishda ro'yxatga olinadi.
2. Baholash: Vaqt, byudjet va xatarlarga ta'siri hisoblanadi.
3. Ko'rib chiqish (CCB — Change Control Board): Rahbariyat va buyurtmachi bilan muhokama.
4. Qaror: Tasdiqlash yoki rad etish.
5. Joriy etish: TZ, reja va byudjet yangilanadi.
6. Yopish: Ish bajarilib, dalolatnoma imzolanadi.

11. Xulosa {#xulosa}

• BRD biznes maqsadini, PRD foydalanuvchi mahsulotini, SRS texnik arxitekturani, TZ esa yuridik majburiyatlarni belgilaydi.
• ISO/IEC/IEEE 29148 talablar aniq, tekshiriluvchan va ziddiyatsiz bo'lishini talab qiladi.
• O'zbekiston amaliyotida eski GOST 34.602-89 o'rniga GOST 34.602-2020 kuchga kirgan.
• Nofunksional talablar (NFR) subyektiv so'zlar bilan emas, o'lchanadigan aniq parametrlar (ms, RPS, %) bilan ifodalanadi.
• Har qanday yangi xohish-istak rasmiy Change Request hujjati orqali muddat va byudjetga to'g'rilanadi.

Manbalar {#manbalar}

1. Business Requirements Document (BRD) Guide — AltexSoft
2. Product Requirements Document (PRD) — ProductPlan
3. Software Requirements Specification (SRS) — Wikipedia
4. IEEE 830 / ISO/IEC/IEEE 29148 — Wikipedia
5. GOST 34.602-2020 Rasmiy matni — GostExpert
6. INVEST in Good Stories — Bill Wake
7. Gherkin Reference — Cucumber Docs
8. ISO/IEC 25010 Software Quality Standards
9. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
10. Requirements Traceability Matrix (RTM) — ReqTest
11. App Store Review Guidelines — Apple Developer
12. Change Control Process — Wikipedia