Yazılım Mühendisliğinde Fonksiyonel Olmayan Gereksinim Nedir?

By: Charles Moore Charles Moore
Hours Güncellenmiş

⚡ Akıllı Özet

İşlevsel Olmayan Gereksinimler, performans, güvenlik, kullanılabilirlik, güvenilirlik, ölçeklenebilirlik ve taşınabilirlik gibi kalite özelliklerini belirterek, bir yazılım sisteminin ne kadar iyi çalışması gerektiğini tanımlar ve belirsiz beklentileri, teslimat yaşam döngüsü boyunca ölçülebilir, test edilebilir ve uygulanabilir mühendislik hedeflerine dönüştürür.

  • 📘 Tanım: İşlevsel Olmayan Gereksinim (NFR), bir sistemin performans, güvenlik, kullanılabilirlik, güvenilirlik ve taşınabilirlik açısından ne kadar iyi performans gösterdiğini açıklar.
  • 🗂️ Ortak türler: Kullanılabilirlik, güvenlik, güvenilirlik, ölçeklenebilirlik, kapasite, erişilebilirlik, bakım kolaylığı ve mevzuat uyumluluğu, ekiplerin değerlendirdiği kategorilerdir. track en sık.
  • 📊 FURPS+ Modeli: FURPS+, işlevsellik, kullanılabilirlik, güvenilirlik, performans, desteklenebilirlik ve tasarım veya arayüz kısıtlamaları gibi işlevsel olmayan gereksinimleri (NFR'ler) gruplandırır.
  • 🎯 Test Edilebilir İfadeler: "Hızlı" veya "güvenli" kelimelerini sayısal eşik değerleri ve doğrulama yöntemleriyle değiştirerek, işlevsel olmayan gereksinimin (NFR) test edilmesini ve kabul edilmesini sağlayın.
  • 🆚 İşlevsel Kontrast: İşlevsel gereksinimler sistemin ne yaptığını belirtirken, işlevsel olmayan gereksinimler sistemin gerçek koşullar altında bunu ne kadar iyi yaptığını belirtir.
  • ✅ İş Etkisi: Eksik işlevsel olmayan gereksinimler (NFR'ler), üretim kazalarının, düzenleyici bulguların ve maliyetli geç aşama mimari yeniden çalışmalarının başlıca nedenidir.
Devamını Oku

Yazılım Mühendisliğinde Fonksiyonel Olmayan Gereksinimler

İşlevsel Olmayan Gereksinim Nedir?

A İşlevsel Olmayan Gereksinim (NFR), bir yazılım sisteminin kalite özelliğini belirtir. NFR'ler, sistemi yanıt verme hızı, kullanılabilirlik, güvenlik, taşınabilirlik ve başarı için kritik olan diğer kalite özelliklerine göre değerlendirir. Yaygın bir işlevsel olmayan gereksinim örneği şöyledir: “web sitesi ne kadar hızlı yükleniyor?” İşlevsel olmayan gereksinimleri karşılayamamak, kullanıcıları hayal kırıklığına uğratan sistemler ortaya çıkarır.

Yazılım mühendisliğinde işlevsel olmayan gereksinimler, çevik geliştirme sürecinde sistem tasarımına kısıtlamalar getirir. Örneğin, eş zamanlı kullanıcı sayısı 10,000'i aştığında sitenin üç saniyede yüklenmesi gerekir. İşlevsel olmayan gereksinimleri tanımlamak, işlevsel gereksinimleri yakalamak kadar önemlidir.

İşlevsel Olmayan Gereksinim Türleri

İşlevsel olmayan gereksinimlerin ana kategorileri şunlardır:

İşlevsel Olmayan Gereksinim Türleri

İşlevsel Olmayan Gereksinim Türleri

  • Kullanılabilirlik
  • Servis
  • idare edilebilirlik
  • kurtarılabilirlik
  • Güvenlik
  • Veri Integrity
  • Kapasite
  • Uygunluk
  • ölçeklenebilirlik
  • Birlikte çalışabilirlik
  • Güvenilirlik
  • İdame
  • Yasal Uygunluk
  • Çevresel kısıtlamalar

İşlevsel Olmayan Gereksinimlere Örnekler

İşte işlevsel olmayan gereksinimlere ilişkin pratik örnekler:

  1. Kullanıcılar ilk başarılı girişten sonra ilk şifrelerini değiştirmelidir ve ilk şifre asla tekrar kullanılmamalıdır.
  2. Çalışanların kendi maaş bilgilerini güncellemelerine izin verilmeyecektir ve bu yöndeki her girişim güvenlik yöneticisine bildirilecektir.
  3. Kullanıcının bir veri öğesine erişme girişimlerinin her başarısız denemesi, denetim izine kaydedilecektir.
  4. Web sitesi, yanıt sürelerinde bozulma olmadan aynı anda 20 milyon kullanıcıyı destekleyecektir.
  5. Yazılım taşınabilir olmalı, böylece bir işletim sisteminden diğerine geçişte herhangi bir sorun yaşanmamalıdır.
  6. Bilgilerin gizliliği, kısıtlı teknolojilerin ihracatı ve fikri mülkiyet hakları denetlenebilir olacaktır.

İşlevsel ve İşlevsel Olmayan Gereksinimler

İşlevsel ve işlevsel olmayan gereksinimler arasındaki temel farklar şunlardır:

Parametreler İşlevsel Gereksinim İşlevsel Olmayan Gereksinim
Nedir? Fiil Özellikler
gereklilik Bu zorunludur Zorunlu değildir
Yakalama türü Kullanım durumunda yakalanır. Bir kalite özelliği olarak yakalanır.
Sonuç Ürün özelliği Ürün özellikleri
Yakalama Yakalanması kolay Yakalanması zor
Hedef Yazılımın işlevselliğini doğrulamanıza yardımcı olur. Yazılımın performansını doğrulamanıza yardımcı olur.
Odak alanı Kullanıcı gereksinimlerine odaklanın Kullanıcının beklentisine odaklanır.
Dökümanlar Ürünün ne işe yaradığını açıklayın Ürünün nasıl çalıştığını açıklar
Test Türü Fonksiyonel Testler Sistem, entegrasyon, uçtan uca, API testleri vb. gibi. Performans, Stres, Kullanılabilirlik, Güvenlik testleri vb. gibi İşlevsel Olmayan Testler.
Test uygulaması Test Yürütme, işlevsel olmayan testlerden önce yapılır. Fonksiyonel testlerden sonra
Ürün Bilgisi Ürün Özellikleri Ürün Özellikleri

İLGİLİ MAKALELER

İşlevsel Olmayan Gereksinimlerin Avantajları

Ana faydaları İşlevsel olmayan testler şunlardır:

  • İşlevsel olmayan gereksinimler, sistemin yasal ve uyumluluk kurallarına uygun olmasını sağlar.
  • Sistem güvenilirliğini, kullanılabilirliğini ve performansını korurlar.
  • İyi bir kullanıcı deneyimi ve kullanım kolaylığı sunuyorlar.
  • Yazılımın güvenlik politikasını şekillendirirler.

İşlevsel Olmayan Gereksinimlerin Dezavantajları

İşlevsel olmayan gereksinimlerin yaygın dezavantajları şunlardır:

  • İşlevsel olmayan gereksinimler, çeşitli üst düzey yazılım alt sistemlerini etkileyebilir.
  • Mimari ve üst düzey tasarım aşamalarında özel değerlendirme gerektirirler, bu da maliyeti artırır.
  • Uygulama nadiren tek bir yazılım alt sistemine karşılık gelir.
  • Mimari aşama tamamlandıktan sonra bunları değiştirmek zordur.

İşlevsel Olmayan Gereksinimlerin Sınıflandırılması için FURPS+ Modeli

FURPS+, işlevsel olmayan gereksinimler için en yaygın kullanılan sınıflandırma sistemidir. Aslen Hewlett-Packard'da geliştirilen bu sistem, kalite özelliklerini beş ana kategoriye ve "+" işaretiyle belirtilen ek kısıtlamalara ayırır. Bu model, İş Analistlerinin bir gereksinim sınıfının tamamını gözden kaçırmasını önlemeye yardımcı olur.

  • Fonksiyonellik: Temel özellik listesinin ötesine geçen yetenek, güvenlik ve yeniden kullanılabilirlik.
  • Kullanılabilirlik: Kullanıcı deneyiminin insan faktörleri, estetik, tutarlılık, dokümantasyon ve yanıt verme hızı.
  • Güvenilirlik: Kullanılabilirlik, arızalar arası ortalama süre, kurtarılabilirlik, öngörülebilirlik ve doğruluk.
  • Performans: Yük altında hız, verimlilik, kapasite, ölçeklenebilirlik ve kaynak tüketimi.
  • Desteklenebilirlik: Teslim edilen sistemin test edilebilirliği, esnekliği, kurulabilirliği, yerelleştirilebilirliği ve bakım kolaylığı.
  • Artı (+): Tasarım, uygulama, arayüz ve gerekli platformlar, standartlar veya donanım gibi fiziksel kısıtlamalar.

İşlevsel olmayan her gereksinimi bir FURPS+ kategorisine eşleştiren ekiplerin, özellikleri karşılayan ancak performans, güvenlik veya sürdürülebilirlik açısından başarısız olan bir sistemi piyasaya sürme olasılığı daha düşüktür.

Test Edilebilir İşlevsel Olmayan Gereksinimler Nasıl Yazılır?

İyi yazılmış işlevsel olmayan bir gereksinim ölçülebilir, doğrulanabilir ve zaman sınırlıdır. "Sistem hızlı olmalı" veya "uygulama güvenli olmalı" gibi belirsiz ifadeler gereksinim değil, beklentilerdir. Bir niyeti test edilebilir bir işlevsel olmayan gereksinime dönüştürmek için aşağıdaki adımları izleyin.

  1. Kalite özelliğini belirleyin. İlgili sorunu bir FURPS+ kategorisine eşleştirin, böylece ekip bunun performans, kullanılabilirlik, güvenlik veya güvenilirlik gereksinimi olup olmadığını anlayabilir.
  2. Bir ölçüt seçin. Her bir işlevsel olmayan gereksinim (NFR) için bir birim gereklidir; milisaniye, saniye başına istek sayısı, eşzamanlı kullanıcı sayısı, çalışma süresi yüzdesi veya ISO 27001 gibi bir uyumluluk standardı.
  3. Sayısal bir eşik değeri belirleyin. “Hızlı” ifadesini “95. yüzdelik dilimde 400 milisaniyenin altında” ile değiştirin. “Yüksek kullanılabilirlik” ifadesini “aylık %99.9 çalışma süresi” ile değiştirin.
  4. Durumu açıklayın. Eşik değerinin geçerli olduğu yükü, ortamı veya kullanıcı segmentini belirtin; örneğin, "aynı anda 10,000 kullanıcının olduğu en yüksek satış dönemlerinde".
  5. Doğrulama yöntemini tanımlayın. Test türünü (yük testi, sızma testi, kaos deneyi, erişilebilirlik denetimi) ve eşik değerini doğrulayacak aracı not edin.
  6. SMART kontrolünü uygulayın. Gereksinimin, iş listesine eklenmeden önce Spesifik, Ölçülebilir, Ulaşılabilir, İlgili ve Zaman Sınırlı olduğundan emin olun.

Örnek yeniden yazım: “Sistem hızlı olmalıdır” ifadesi şu şekilde değiştirilir: “Ödeme sayfası, 5,000 eş zamanlı kullanıcıyla %95'lik dilimde 500 milisaniyenin altında yanıt vermelidir; bu, bir JMeter "Her sürümde yük testi yapın." Bu revize edilmiş ifade, geliştiricilerin buna göre tasarım yapmasına, test uzmanlarının bunu doğrulamasına ve ürün sahiplerinin itirazsız kabul etmesine olanak tanıyor.

SSS

Yapay zekâ destekli yük ve performans araçları, gerçekçi trafik oluşturur, yanıt süresi dağılımlarındaki anormallikleri tespit eder ve üretim öncesinde ölçeklendirme sınırlarını tahmin eder. Yapay zekâ ayrıca, geleneksel kural tabanlı araçların gözden kaçırdığı güvenlik olaylarını işaretlemek için günlükleri ve erişim modellerini inceler.

Copilot ve GPT, belirsiz kalite ifadelerini ölçülebilir, eşik değer, koşul ve doğrulama yöntemi içeren işlevsel olmayan gereksinimlere (NFR) dönüştürür. İş analistleri, her taslağı FURPS+ kategorileri ve SMART çerçevesine göre inceleyerek, iş listesine kabul etmeden önce değerlendirir.

Fonksiyonel testler, oturum açma veya arama gibi özelliklerin doğru çalışıp çalışmadığını kontrol eder. Fonksiyonel olmayan testler ise sistemin yük, stres ve kullanım altında ne kadar iyi performans gösterdiğini ölçer ve performans, güvenlik, kullanılabilirlik, uyumluluk ve güvenilirlik hedeflerini kapsar.

Ölçeklenebilirlik, kullanılabilirlik, gecikme süresi, esneklik ve maliyet verimliliği, bulut bilişimde temel işlevsellik gereksinimlerinin (NFR) başında geliyor. Ekipler ayrıca... tracGözlemlenebilirlik, RPO ve RTO gibi felaket kurtarma hedefleri ve çok bölgeli uyumluluk, bulut mimarisi kararlarının çoğunu yönlendirdiği için önemlidir.

Birim içeren bir ölçüt seçin, sayısal bir eşik belirleyin, uygulanacağı koşulu açıklayın ve doğrulama yöntemini adlandırın. Örneğin, 5,000 kullanıcıda %95'lik dilimde 400 milisaniyenin altında yanıt süresi, aşağıdaki yöntemle doğrulanmıştır: JMeter.

Verilerin depolanması ve iletilmesi sırasında şifrelenmesi, kimlik doğrulama gücü, rol tabanlı yetkilendirme, denetim kaydı, oturum zaman aşımı ve ISO 27001, PCI DSS ve GDPR gibi standartlara uyumluluk, çoğu ekibin belgelediği güvenlik temel işlevsel gereksinimleridir (NFR).

Belirsiz sıfatlar kullanmak, ölçütü veya koşulu atlamak, işlevsel olmayan gereksinimleri (NFR'ler) yalnızca projenin sonunda listelemek ve hiçbir testin doğrulayamayacağı hazır şablonları kopyala yapıştır yapmak, mimarinin geç aşamalarında yeniden düzenlenmesine yol açan en yaygın hatalardır.

İşlevsel olmayan gereksinimler (NFR'ler), yazılım gereksinimleri spesifikasyonunda, mimari karar kayıtlarında, hizmet seviyesi anlaşmalarında ve tamamlanma tanımı kontrol listelerinde yer alır. Çevik ekipler genellikle ölçülebilir NFR'leri epiklere ve her kullanıcı hikayesinin tamamlanma tanımına ekler.

Bu yazıyı şu şekilde özetleyin: