Qeyri-funksional tələblər: kritik olanı unutmayaq

Giriş

Heç olubmu ki, funksionallığı tam hazırlamısınız, amma istifadəçilər şikayət edir: “Çox yavaşdır” və ya “Tez-tez çökür”? Problem — qeyri-funksional tələblərin (Non-Functional Requirements, NFRs) nəzərə alınmamasıdır.

Qeyri-funksional tələblər sistemin nə etdiyini deyil, necə yaxşı etdiyini müəyyən edir. Onlar performans, təhlükəsizlik, etibarlılıq, istifadənin rahatlığı və miqyaslana bilənlik kimi xüsusiyyətləri əhatə edir. Bu tələbləri unutmaq əlavə xərclərə, istifadəçilərin narazılığına və layihənin iflasına gətirib çıxara bilər.

Qeyri-funksional tələblər nədir?

Funksional tələb: “İstifadəçi sifariş verə bilər.”
Qeyri-funksional tələb: “Sistem sifarişi 2 saniyədən gec olmayaraq emal etməlidir” və ya “Sistem eyni vaxtda 10 000 istifadəçini dəstəkləməlidir.”

Yəni qeyri-funksional tələblər funksionallıqla istifadəçi təcrübəsi arasında körpü rolunu oynayır. Funksiya işləyə bilər, amma əgər keyfiyyət zəifdirsə, istifadəçi narazı qalacaq.

Niyə qeyri-funksional tələblər çox vaxt unudulur?

Əsas səbəblər:

• Komandalar gözə çarpan funksionallığı prioritetləşdirir.
• Onları ölçmək və formalizasiya etmək çətindir.
• Layihənin əvvəlində nəticə tez göstərilmək istənilir və NFR-lər “opsional” kimi qəbul olunur.

Amma bu, böyük səhvdir. Təsəvvür edin: onlayn mağaza çox funksiyaya malikdir, amma səhifə 15 saniyəyə açılır. İstifadəçi sadəcə rəqibə keçəcək.

Agile-də qeyri-funksional tələblər

Bəzi Agile komandaları düşünür ki, işlək proqram — yalnız funksionallıqdır. Əslində isə qeyri-funksional tələblər başlanğıcdan inteqrasiya olunmalıdır. Yaxşı təcrübələr:

• Qeyri-funksional tələbləri Definition of Done-a daxil edin.
• Onları product backlog-da funksional tələblərlə yanaşı yazın.
• Ölçülə bilən metriklər təyin edin (məs: “99.9% uptime” və ya “server cavabı ≤ 200 ms”).

Belə olduqda NFR-lər dəyərin bir hissəsinə çevrilir, əlavə yük kimi yox.

Əsas kateqoriyalar

• Performans: cavab müddəti, bant genişliyi, emal sürəti.
• Təhlükəsizlik: məlumatların qorunması, girişə nəzarət, şifrələmə.
• Etibarlılıq: sistemin əlçatanlığı, xətaların idarə olunması.
• İstifadə rahatlığı: sadə interfeys, öyrənmə asanlığı, əlçatanlıq.
• Miqyaslana bilənlik: istifadəçi yükünün və məlumatların artımını dəstəkləmək.

Bunlar sistemin sadəcə işləməsini deyil, keyfiyyətli işləməsini təmin edir.

Real nümunələr

• Performans: Bank sistemində performans tələbləri yazılmadı. Nəticə: 30 saniyəlik cavab müddəti və yenidənqurma zərurəti.
• Təhlükəsizlik: E-commerce tətbiqində iki faktorlu autentifikasiya nəzərə alınmadı. Hesablar sındırıldı, şirkət böyük zərər gördü.
• Miqyaslana bilənlik: Startap miqyaslanma nəzərdə tutmadı. İstifadəçi sayı artanda sayt çökməyə başladı və təcili miqrasiya lazım oldu.

Çek-list: qeyri-funksional tələblərlə işləmək üçün

• Layihənin əvvəlindən maraqlı tərəflərlə NFR-ləri müzakirə edin.
• Ölçülə bilən formada yazın (saniyə, faiz, rəqəm).
• Onları Definition of Done-a daxil edin.
• Funksional tələblər kimi test edin.
• Məhsul böyüdükcə NFR-ləri yeniləyin.

Nəticə

Qeyri-funksional tələblər məhsulun etibarlı, təhlükəsiz və rəqabətədavamlı olmasını müəyyən edir. Onları nəzərə almamaq — layihəni ciddi risklərə atmaqdır.

NFR-ləri erkən mərhələdən prioritet edin, backlog-a əlavə edin və yoxlama strategiyasına daxil edin.

Bəs siz hansı kritik qeyri-funksional tələbi az qala unutmuşdunuz? Təcrübənizi şərhlərdə paylaşın və məqaləni «Bəyəndim» və ya «Bəyənmədim» düymələri ilə qiymətləndirin.