Cevap.

Tarihsel olarak, IT projelerinde ana odak işlevsel gereksinimlere verilmiştir: sistemin ne yapması gerektiği. Bu arada, performans, güvenilirlik, ölçeklenebilirlik, erişilebilirlik, güvenlik ve sürdürülebilirlik gibi konular (bu özellikler "işletim dışı gereksinimler" terimi altında toplanır) uzun süre ikincil kalmış ve çoğu zaman hiç formüle edilmemiştir.

Problem

İşletim dışı gereksinimlerin göz ardı edilmesi veya resmi olarak tanımlanmaması, işletme sırasında önemli sorunlara yol açar: sistem, beklenen yükler için hazır olmamakta, siber saldırılara dayanamayarak, desteklenmesi ve ölçeklendirilmesi zor hale gelmekte veya gerekli sayıda kullanıcıya erişilememektedir.

Çözüm

Modern bir sistem analisti, işletim dışı gereksinimleri başlatmak, formüle etmek, analiz etmek ve belgelemekle yükümlüdür. Bu, şunları içerir:

Teknolojik ve altyapısal kısıtlamaları belirlemek için mimarlar, DevOps ve işletme ekipleri ile etkileşim;
İşten gereksinimlerin toplanması (örneğin, SLA üzerinden);
Belirli eşik değerleri ile kapsamlı bir işletim dışı gereksinim listesi oluşturma;
Uygulama ve destek aşamalarında bunların denetimi için önlemler alma;
Gereksinimleri teknik şartname içinde ayrı bölümlerde kaydetme.

Anahtar özellikler:

İşletim dışı gereksinimler, herhangi bir büyük proje için gereklidir.
Teknik ve iş paydaşları ile birlikte belirlenir.
Açık, test edilebilir ve iş hedeflerine bağlanmalıdır.

Çelişkili Sorular.

"Ürün kalitesi" ile "işletim dışı gereksinimler" arasındaki fark nedir?

Ürün kalitesi, yalnızca formüle edilebilir parametreleri değil, aynı zamanda öznel değerlendirmeleri (örneğin, UX/UI kullanışlılığı) içeren daha geniş bir kavramdır. İşletim dışı gereksinimler, otomatik doğrulamaya tabi tutulabilen (performans, güvenilirlik vb.) kesin ölçülebilir özelliklerdir.

Analist, tüm işletim dışı gereksinimlerin belirlenmesini mimara devredebilir mi?

Hayır, analist, bu gereksinimleri analiz aşamasında mimar ve iş ile birlikte belirlemekle yükümlüdür; aksi takdirde gereksinimler eksik ya da yalnızca teknik açıdan tanımlanmış olur, iş ihtiyaçları göz önünde bulundurulmaz.

İşletim dışı gereksinimleri yalnızca genel ifadelerle ("sistem güvenilir olmalıdır") ifade etmek mümkün mü?

Hayır, bu tür ifadeler denetim ve test için uygunsuzdur. Spesifikasyon gereklidir: örneğin, "hizmetin arıza sonrası tekrar çalışması 10 dakikayı geçmemelidir".

Yaygın Hatalar ve Anti-Şemalar

Test edilebilir kriterler olmadan gereksinimlerin formüle edilmesi ("hızlı", "şahane", "güvenilir").
Belirli işletim dışı gereksinim sınıflarının atlanması (örneğin, iç sistemler için güvenlik).
Müşteri ve destek arasındaki gereksinimlerin tutarsızlığı.

Hayattan Bir Örnek

Olumsuz durum: Ulusal hizmet portalının projesi, pik yükler için gereksinimleri formüle etmemiştir. Sistem, popüler hizmetlerin başlatıldığı günlerde "çökmüş", güvenlik olayları ortaya çıkmıştır.

Artıları:

Hızlı MVP

Eksileri:

Geliştirme için büyük maliyetler
Kullanıcıların güven kaybı
Destek için zorluklar

Olumlu durum: Bir endüstriyel otomasyon fabrikası projesinin başlangıcında analist, iş ile birlikte sistemin durma sürelerinin yeni işlevlerden daha önemli olduğunu belirlemiştir. SLA, acil senaryolar geliştirmiş ve belirli metrikler yazmıştır.