30 saniyelik özet
Non-Functional Requirement, yani fonksiyonel olmayan gereksinim, çözümün hangi kalite düzeyinde ve hangi koşullarda çalışması gerektiğini tanımlar. Performans, kullanılabilirlik, güvenilirlik, ölçeklenebilirlik ve bakım yapılabilirlik bu beklentiler arasındadır. “Hızlı” veya “kullanıcı dostu” demek yeterli değildir; bağlam, ölçüm ve kabul koşulu gerekir. İş analisti bu beklentileri iş ihtiyacıyla ilişkilendirir. Teknik ekip ve ilgili paydaşlarla birlikte uygulanabilir hedefler belirlenir; doğrulama yalnızca teslimatın sonunda düşünülmez.
Neden önemli?
Bir rapor doğru hesaplanabilir, ancak yönetim toplantısında kullanılamayacak kadar geç açılabilir. Sipariş sistemi bütün işlevleri sağlayabilir, fakat kampanya yoğunluğunda işlemleri tamamlayamayabilir. Fonksiyonel doğruluk önemlidir; gerçek çalışma koşullarındaki kalite de çözümün işletme değerini belirler.
Bu beklentiler geç ele alındığında maliyet artabilir. Başlangıçta uygun görünen tasarım, büyüyen veri hacmini veya hata sonrası toparlanmayı karşılamayabilir. Sonradan yapılacak değişiklik yalnızca bir ayardan ibaret olmayabilir; veri düzenini, sistem bağlantılarını ve operasyon biçimini etkileyebilir.
Junior bir iş analisti için bu çalışma, kalite sıfatlarını araştırılabilir sorulara dönüştürme becerisidir. Hız kimin için, hangi işlemde ve hangi koşullarda önemli? Kesinti hangi iş sonucunu etkiler? Yönetici için ise kalite hedefleri bir kaynak tercihidir. Her beklentinin aynı anda en yüksek düzeyde karşılanması mümkün veya ekonomik olmayabilir.
Endüstri mühendisliği açısından kapasite, değişkenlik ve hizmet düzeyi birlikte değerlendirilir. Ortalama yükte başarılı bir sistem, yoğunluğun kısa süreli arttığı koşullarda farklı davranabilir. Bu nedenle yalnızca tipik kullanıcıyı veya ortalama işlem süresini değerlendirmek, işletme açısından önemli gecikmeleri görünmez bırakabilir.
Terim nedir?
Fonksiyonel gereksinim sistemin ne yapacağını, fonksiyonel olmayan gereksinim ise bu davranışın kalite beklentilerini ve çalışma koşullarını açıklar. Rapor oluşturmak bir işlevdir. Belirlenmiş veri hacmi ve yük altında raporun kabul edilen sürede hazır olması bir performans koşuludur. İki tür gereksinim birlikte ele alınmalıdır.
NFR, Non-Functional Requirement ifadesinin kısaltmasıdır. Bu sınıflandırma kalite gereksinimlerini gözden kaçırmamak için yararlıdır; ancak bütün konular kesin biçimde ikiye ayrılamaz. Güvenlik, örneğin, hem yetki kontrolü gibi işlevler hem de sistemin korunmasına ilişkin kalite koşulları içerebilir. Önemli olan davranışın ve doğrulamanın açıklığıdır.
Performans gereksiniminde işlem, veri hacmi, yük ve ölçüm sınırı belirtilir. Kullanıcının talebi başlattığı an ile sonucunu görebildiği an arasındaki süre, yalnızca sunucudaki hesaplama süresinden farklıdır. Hangi sürenin değerlendirildiği yazılmalıdır. Test ortamının gerçek kullanımla ilişkisi de açıklanmalıdır.
Ortalamalar bazı gecikmeleri gizleyebilir. Yüzdelik dilimler, ölçümlerin belirli bir bölümünün hangi sürenin altında kaldığını gösterir. Örneğin P95, ölçümlerin yüzde 95’inin aşmadığı süreyi ifade eder. Bu, bütün kullanıcıların aynı sürede sonuç aldığı anlamına gelmez. Hedef seçimi, iş ihtiyacı ve gözlenen davranışa dayanmalıdır.
Erişilebilirlik, farklı yeteneklere sahip kişilerin çözümü kullanabilmesine ilişkin beklentileri içerir. Hizmetin kullanılabilirliği ise hizmetin çalışır durumda olmasını anlatır. Aynı kelimelerin farklı anlamlarda kullanılması beklentiyi belirsizleştirebilir. Gereksinimlerde ölçülen özelliğin açıkça belirtilmesi gerekir.
Güvenilirlik ve toparlanma koşulları da iş bağlamına dayanır. Hangi arızada hangi işlemler devam edecek, ne kadar veri kaybı kabul edilebilir ve hizmet nasıl geri getirilecek? Bu soruların cevapları işletmenin risk tercihleriyle teknik olanakları birlikte değerlendirmeyi gerektirir. “Hiç kesilmesin” ifadesi tek başına uygulanabilir bir karar oluşturmaz.
Kalite gereksinimi bir ölçülebilir hedef içerebilir; fakat her konu tek sayıya indirgenemez. Kullanılabilirlik için tanımlı kullanıcı görevleri, başarı koşulları ve değerlendirme yöntemi kullanılabilir. Gereksinimin doğrulanabilir olması, mutlaka tek bir eşik yazılması anlamına gelmez. Koşulların ve değerlendirme ölçütünün anlaşılması gerekir.
Gerçek vaka: Shopify’ın yoğun trafik hazırlığı
Shopify’ın mühendislik yazısı, Black Friday ve Cyber Monday alışveriş dönemine hazırlık için kapasite planlama, dayanıklılık ve geniş ölçekli yük testlerini anlatıyor. Testler alışveriş, yönetim paneli ve kampanya akışları gibi farklı kullanıcı yolculuklarını temsil ediyor. Amaç yalnızca işlemlerin doğru olması değil, beklenen yoğunlukta tamamlanabilmesi.
Kaynak, bazı denemelerde bir bölgenin hizmet dışı kalmasının da sınandığını açıklıyor. Bulgular ilgili ekiplere atanıyor, iyileştirmeler yapılıyor ve sonraki testlerde yeniden değerlendiriliyor. Böylece kalite beklentisi tek seferlik bir kontrol yerine tekrar edilen bir çalışmaya dönüşüyor.
Yazının önemli bir sınırı da var: Üretilen test yükünün gerçek kullanıcı trafiğini tam olarak temsil etmediği belirtiliyor. Dolayısıyla testin geçilmesi bütün üretim koşullarında başarı garantisi sayılmıyor. Bu vaka, kalite gereksinimlerini doğrularken yükün niteliğinin, bağımlılıkların ve test koşullarının da değerlendirilmesi gerektiğini gösteriyor.
Varsayımsal örnek: Aylık kapanışta kullanılan raporlama uygulaması
İşletmelere raporlama yazılımı sunan bir şirketin, müşterilerin aylık kapanış işlemlerinde uygulamanın yavaşladığını gördüğünü düşünelim. İlk talep “raporlar daha hızlı açılsın” olsun. Analist, bu ifadeyi doğrudan teknik ekibe görev olarak iletmeden kullanım koşullarını araştırır.
Önce hangi raporların, hangi veri büyüklüğünde ve hangi kullanıcı gruplarında geciktiği incelenir. Aynı anda rapor açma, veri aktarma ve dosya indirme işlemlerinin nasıl birleştiği değerlendirilir. Eşzamanlı kullanıcı sayısı tek başına yeterli değildir; kullanıcıların yaptığı işlemler farklı kaynak ihtiyaçları yaratabilir.
Gereksinim adayı şöyle kurulabilir: “Tanımlanan standart rapor grubu, doğrulanmış veri hacmi ve yük profili altında, onaylanan süre hedefini karşılamalıdır.” Veri hacmi, yük profili, süre hedefi ve değerlendirilecek ölçüm ayrıca yazılır. Bu bilgiler henüz ölçülmemişse belgeyi tamamlamak için rakam eklenmez; ölçüm ve karar çalışması planlanır.
Büyük dosya üretiminin kullanıcıyı bekletmeden yürütülmesi çözüm seçeneği olabilir. İşlemin arka planda yapılması ve durumunun kullanıcıya gösterilmesi fonksiyonel davranışlardır. Raporun ne kadar sürede tamamlanacağı, başka işlemlerin performansını nasıl etkileyeceği ve başarısızlıkta toparlanma beklentisi ise ayrıca değerlendirilir.
Müşterilerin verilerinin birbirinden ayrılması, yetkilerin korunması ve hataların takip edilebilmesi de incelenir. Hız kazanmak için gerekli kontrollerin kaldırılması kabul edilmez. Teknik ekip, seçeneklerin maliyetini ve etkisini açıklar; iş sahipleri hangi kalite düzeyinin gerekli olduğunu gerekçesiyle belirler.
Doğrulamada normal dönem ve kapanış yükü ayrı senaryolarla değerlendirilir. Test sonucuyla gerçek kullanım arasındaki fark izlenir. Üçüncü taraf gecikmelerinin kullanıcıya etkisi ayrıca görünür tutulur; bunları ölçümden çıkarmak müşterinin yaşadığı sorunu ortadan kaldırmaz. Gereksinim, hangi sınırda neyin değerlendirildiğini açıkça göstermelidir.
Yaygın üç hata
- Kaliteyi sıfatlarla bırakmak. “Hızlı”, “güvenli” ve “kolay” farklı kişiler için farklı beklentiler yaratır. İlgili kullanıcı görevini, çalışma koşulunu ve değerlendirme yöntemini açıklayın. Teknik ekibin tahminini işletmenin onaylanmış beklentisi gibi kabul etmeyin.
- Yalnızca ortalama ve normal yükü ölçmek. Yoğun dönem, büyük veri veya bağımlılık arızası önemli sonuçlar yaratabilir. İş açısından gerekli senaryoları belirleyin. Her uç koşulu aynı seviyede desteklemek zorunda değilsiniz; fakat sınırları ve etkileri bilinçli olarak kararlaştırın.
- Doğrulamayı teslimat sonuna bırakmak. Kalite koşulları mimari ve kapasite kararlarını etkileyebilir. Gereksinimleri erken değerlendirin, riskli varsayımları uygun denemelerle sınayın. Son testte bulunan bir sorun, planlanmış teslimatın ötesinde çalışma gerektirebilir.
Mini uygulama: Kalite gereksinimi kartı
Bir kullanıcı işlemi seçin ve aşağıdaki alanları doldurun. Hedef değeri belirlemeden önce mevcut durumu ve işletme ihtiyacını araştırın.
- Kalite özelliği
- Hangi beklenti değerlendiriliyor?
- İş gerekçesi
- Karşılanmazsa hangi sonuç etkilenir?
- İşlem ve kullanıcı grubu
- Hangi davranış kapsamda?
- Çalışma koşulu
- Veri, yük ve bağımlılıklar nasıl tanımlanıyor?
- Ölçüm sınırı
- Nereden başlayıp nerede bitiyor?
- Kabul ölçütü
- Hangi sonuç yeterli sayılacak?
- Doğrulama
- Hangi yöntem ve ortam kullanılacak?
- Sınırlamalar
- Test hangi koşulları temsil etmiyor?
- Sorumlu
- Hedefi ve sonucu kim değerlendirecek?
- Takip
- Kullanım sırasında değişim nasıl izlenecek?
Kartı iş sahibi, teknik ekip ve test sorumlusuyla birlikte inceleyin. Aynı hedefin aynı şekilde ölçüleceğinden emin olun. Kalite gereksiniminin değeri iddialı sözler vermekte değil, işletmenin ihtiyaç duyduğu çalışma düzeyini anlaşılır ve değerlendirilebilir hâle getirmektedir.
İlgili terimler
Functional Requirement, Business Requirement, Business Objective, Acceptance Criteria, Scope ve Out of Scope, Feasibility Study, API Specification / API Contract, KPI ve Metrics, Dependency Management, Risk Register and Response Planning, Change Request ve Impact Analysis