Dasturiy injiniringa kirish

Funktsional bo'lmagan talablar
Funktsional bo'lmagan talablar, nomidan ko'rinib turibdiki, tizim tomonidan foydalanuvchilarga taqdim etiladigan muayyan xizmatlar bilan bevosita bog'liq bo'lmagan talablardir. Ushbu funktsional bo'lmagan talablar odatda butun tizimning xususiyatlarini belgilaydi yoki cheklaydi. Ular ishonchlilik, javob vaqti va xotiradan foydalanish kabi favqulodda tizim xususiyatlariga tegishli bo'lishi mumkin. Shu bilan bir qatorda, ular tizimni amalga oshirishdagi cheklovlarni, masalan, kiritish-chiqarish qurilmalarining imkoniyatlari yoki ­boshqa tizimlar bilan interfeyslarda qo'llaniladigan ma'lumotlarni taqdim etishni belgilashlari mumkin.
Funktsional bo'lmagan talablar ko'pincha individual funktsional talablarga qaraganda muhimroqdir. Tizim foydalanuvchilari odatda o'zlarining ehtiyojlariga to'g'ri kelmaydigan tizim funksiyasi atrofida ishlash yo'llarini topishlari mumkin. Biroq, funktsional bo'lmagan talabni qondirmaslik butun tizimning yaroqsizligini anglatishi mumkin. Masalan, agar samolyot tizimi ishonchlilik talablariga javob bermasa, u foydalanish uchun xavfsiz deb sertifikatlanmaydi; agar o'rnatilgan boshqaruv tizimi ishlash talablariga javob bermasa, boshqaruv funktsiyalari to'g'ri ishlamaydi.
Qaysi tizim komponentlari o'ziga xos funktsional talablarni amalga oshirishini aniqlash mumkin bo'lsa-da ­( masalan, hisobot berish talablarini bajaradigan formatlash komponentlari bo'lishi mumkin ­), bu ko'pincha funktsional bo'lmagan talablar bilan qiyinroq. Ushbu talablarni amalga oshirish ikki sababga ko'ra butun tizimga tarqalishi mumkin:
Funktsional bo'lmagan talablar alohida komponentlarga emas, balki tizimning umumiy arxitekturasiga ta'sir qilishi mumkin. Masalan, o'rnatilgan tizimda ishlash talablari bajarilishini ta'minlash uchun siz tizimni komponentlar orasidagi aloqani minimallashtirish uchun tashkil qilishingiz kerak bo'lishi mumkin.
Dasturiy ta’minot talablar xujjati (Software Requirements Document)
Talablar muhandisligi uchta asosiy faoliyatni o'z ichiga oladi. Bu manfaatdor tomonlar bilan o'zaro hamkorlik qilish orqali talablarni aniqlash (aniqlash va tahlil qilish); ushbu talablarni standart shaklga (spetsifikatsiyaga) aylantirish; va talablar mijoz xohlagan tizimni aniq belgilashini tekshirish (validatsiya). Bularni 2.4 -rasmda ketma-ket jarayonlar sifatida ko'rsatdim . Biroq, amalda, talablar muhandisligi iterativ jarayon bo'lib, unda harakatlar bir-biriga aralashib ketadi.
Yuqoridagi jadvalda aralashishni ko'rsatadi. Faoliyatlar spiral atrofida takrorlanuvchi jarayon sifatida tashkil etilgan. RE jarayonining natijasi tizim talablari hujjatidir ­. Takrorlashda har bir faoliyatga ajratilgan vaqt va kuch miqdori umumiy jarayonning bosqichiga, ishlab chiqilayotgan tizim turiga va mavjud byudjetga bog'liq.
Jarayonning boshida ko'p kuch yuqori darajadagi biznes va funktsional bo'lmagan talablarni va tizim uchun foydalanuvchi talablarini tushunishga sarflanadi. Keyinchalik, jarayonda, spiralning tashqi halqalarida, funktsional bo'lmagan talablarni va batafsilroq tizim talablarini aniqlash va tushunishga ko'proq kuch sarflanadi. Talablar turli darajadagi tafsilotlargacha ishlab chiqilgan rivojlanishga yondashuvlarni o'z ichiga oladi. ­Spiral atrofidagi iteratsiyalar soni har xil bo'lishi mumkin, shuning uchun spiraldan foydalanuvchi ­talablarining bir qismi yoki barchasi aniqlangandan keyin chiqish mumkin. Talablar va tizimni amalga oshirish birgalikda ishlab chiqilishi uchun prototiplash o'rniga Agile rivojlanishdan foydalanish mumkin .
Deyarli barcha tizimlarda talablar o'zgaradi. Ishtirokchilar ­dasturiy ta'minot nima qilishni xohlashlarini yaxshiroq tushunishadi; tizimni sotib olgan tashkilot o'zgaradi; va tizimning apparat, dasturiy ta'minoti va tashkiliy muhitiga o'zgartirishlar kiritiladi. O'zgarishlarni boshqa talablarga ta'sirini va o'zgarishlarni amalga oshirishning xarajatlari va tizim oqibatlarini tushunish uchun boshqarish kerak.
Foydalanilgan adabiyotlar va internet manba’lar

1. 
   Ian Sommerville. SOFTWARE ENGINERING. 10th Edition. England Pearson Education Limited 2016.
   
2. 
   Piyerre Bourquye, Fairley R.E. GUIDE TO THE SOFTWARE ENGINEYeRING Body of Knowledge. Version 3.0. SVEBOK. A Project of the Ye Computer Sociyety. 2014. 355 page.
   
3. 
   https://ru.wikipedia.org
   
4. 
   https://hozir.org