Fonksiyonel mi, Fonksiyonel Olmayan Gereksinim mi? Ne ile Nasıl Arasındaki Çizgi

Temel ayrım: Ne yapmalı, ne kadar iyi yapmalı?

Fonksiyonel gereksinim, sistemin belirli bir girdiye karşılık ne yapması gerektiğini tanımlar: hangi işlemi gerçekleştireceğini, hangi veriyi işleyeceğini, hangi çıktıyı üreteceğini. "Müşteri, siparişini teslim edilmeden önce iptal edebilmelidir" ya da "Sistem, onaylanan her fatura için muhasebe kaydı oluşturmalıdır" fonksiyonel gereksinimlerdir. Karşılanıp karşılanmadığı genellikle evet ya da hayır ile test edilir.

Fonksiyonel olmayan gereksinim ise sistemin bu işleri hangi nitelikte yapması gerektiğini anlatır: ne kadar hızlı, ne kadar güvenli, ne kadar erişilebilir, ne kadar kolay bakım yapılabilir. "Sipariş iptal ekranı, yoğun kullanım saatlerinde de belirlenen yanıt süresi içinde açılmalıdır" ya da "Kişisel veriler yalnız yetkili rollerce görüntülenebilmelidir" bu türe örnektir. Bunlara kalite nitelikleri ya da kalite gereksinimleri de denir.

Pratik bir ayırt etme sorusu: Bu gereksinimi ortadan kaldırırsam sistem bir işi hiç yapamaz mı (fonksiyonel), yoksa işi yapar ama kötü mü yapar (fonksiyonel olmayan)?

Ortak zemin: Aynı kalite kuralları

Gereksinimin türü ne olursa olsun, iyi bir gereksinimden beklenen nitelikler aynıdır: • Açık ve tek anlamlı: Farklı okuyucular aynı şeyi anlamalı. • Doğrulanabilir: Karşılanıp karşılanmadığı bir test, inceleme ya da ölçümle gösterilebilmeli. • Gerekli: Bir iş ihtiyacına ya da paydaş beklentisine izlenebilmeli. • Uygulanabilir: Teknik, bütçe ve zaman kısıtları içinde gerçekleştirilebilmeli. • Tutarlı: Diğer gereksinimlerle çelişmemeli.

İş analizi pratiğinde (örneğin BABOK Rehberi'nin sınıflandırmasında) fonksiyonel ve fonksiyonel olmayan gereksinimler çözüm gereksinimlerinin alt türleri olarak ele alınır; yani iş ve paydaş ihtiyaçlarından türetilirler ve kaynakları bilinmelidir. Bu türlerin her biri izlenebilirlik matrisinde iş hedeflerine ve test senaryolarına bağlanmalıdır.

Ölçüt ölçüt fonksiyonel ve fonksiyonel olmayan gereksinim

• Yanıtladığı soru: Fonksiyonel / sistem ne yapmalı? Fonksiyonel olmayan / sistem bunu ne kadar iyi, hangi koşullarda yapmalı?
• Kapsam: Fonksiyonel / genellikle belirli bir özellik ya da kullanım senaryosuyla sınırlıdır. Fonksiyonel olmayan / çoğunlukla sistemin tamamını ya da birçok özelliği kesen niteliklerdir.
• Tipik kategoriler: Fonksiyonel / iş kuralları, hesaplamalar, veri işleme, yetkilendirme mantığı, raporlar, entegrasyon davranışı. Fonksiyonel olmayan / performans, güvenlik, güvenilirlik, kullanılabilirlik, erişilebilirlik, bakım yapılabilirlik, ölçeklenebilirlik, uyumluluk.
• Yazım biçimi: Fonksiyonel / kullanıcı hikâyesi, kullanım senaryosu, iş kuralı tablosu. Fonksiyonel olmayan / ölçülebilir eşik, koşul ve ölçüm yöntemi içeren cümle.
• Doğrulama: Fonksiyonel / fonksiyonel test, kabul testi. Fonksiyonel olmayan / yük ve performans testi, güvenlik testi, erişilebilirlik denetimi, kod analizi.
• Gözden kaçma riski: Fonksiyonel / düşük, paydaşlar doğrudan ister. Fonksiyonel olmayan / yüksek, paydaşlar bunları "zaten olması gereken" diye dile getirmeyebilir.
• Değişim sıklığı: Fonksiyonel / iş kuralları ve süreçler değiştikçe sık güncellenir. Fonksiyonel olmayan / daha kalıcıdır, ancak kullanıcı sayısı, mevzuat ya da hizmet seviyesi beklentisi değiştiğinde yeniden ele alınır.
• Mimariye etkisi: Fonksiyonel / genellikle bileşen düzeyinde. Fonksiyonel olmayan / teknoloji, altyapı ve mimari kararları doğrudan belirler.

Fonksiyonel olmayan gereksinim nasıl ölçülebilir yazılır?

"Sistem hızlı olmalı", "uygulama güvenli olmalı", "arayüz kullanıcı dostu olmalı" gibi ifadeler gereksinim değil, dilektir; test edilemezler. Ölçülebilir bir fonksiyonel olmayan gereksinim şu öğeleri içerir: • Kapsam: Hangi işlem, ekran ya da servis için geçerli? • Koşul: Hangi yük, kullanıcı tipi ya da ortamda? • Ölçüt ve eşik: Hangi metrikle, hangi sınır değerle? • Ölçüm yöntemi: Hangi araçla, hangi testle doğrulanacak?

Örneğin "Ödeme sayfası hızlı açılmalı" yerine "Ödeme sayfası, kampanya dönemindeki beklenen eşzamanlı kullanıcı yükünde, isteklerin kararlaştırılan yüzdelik dilimi için belirlenen saniye sınırının altında yanıt vermelidir; ölçüm yük testi aracıyla yapılır" yazılır. Eşik değerleri ürün sahibi, mimar ve operasyon ekibi birlikte belirler ve sayısal olarak gereksinim belgesine işlenir.

Yazılım ürün kalitesini sınıflandırmak için ISO/IEC 25010 ürün kalite modeli ortak bir başlık listesi sunar; fonksiyonel olmayan gereksinimleri derlerken bir kontrol listesi olarak kullanılabilir.

Sınırdaki örnekler: Hangisi hangisi?

Bazı gereksinimlerin ilk bakışta hangi türe ait olduğu belirsizdir: • Güvenlik: "Kullanıcı, belirli sayıda hatalı girişten sonra hesabını geçici olarak kilitlenmiş görmelidir" bir davranış tanımladığı için fonksiyoneldir. "Sistem yetkisiz erişime karşı korunmalıdır" ise bir kalite niteliğidir ve ancak somut kontrollere ayrıştırıldığında test edilebilir. • Raporlama: "Yönetici aylık satış raporunu bölge kırılımıyla alabilmelidir" fonksiyoneldir; "Rapor, yoğun veri hacminde de kabul edilebilir sürede üretilmelidir" fonksiyonel olmayandır. • Denetim izi: Kimin hangi kaydı ne zaman değiştirdiğinin tutulması, mevzuat gereği olsa bile sistemin yaptığı bir iş olduğu için fonksiyonel gereksinim olarak yazılır.

Sık görülen bir yaklaşım, fonksiyonel olmayan bir niteliği karşılamak için gereken davranışları ayrı fonksiyonel gereksinimlere dönüştürmektir. Örneğin güvenlik niteliği; parola politikası, oturum zaman aşımı ve rol bazlı yetki gibi somut, test edilebilir fonksiyonel gereksinimlere ayrıştırılır.

Sık yapılan hatalar

• Fonksiyonel olmayan gereksinimleri hiç sormamak: Paydaşlar performans ve güvenliği varsayılan kabul eder; bu beklentiler proje sonunda canlıya geçişte sorun olarak ortaya çıkar.
• Ölçülemeyen sıfatlar kullanmak: "Hızlı", "kolay", "sağlam" gibi kelimeler test ekibine doğrulanabilir bir hedef vermez.
• Çevik ekiplerde bu gereksinimleri kaybetmek: Kullanıcı hikâyeleri fonksiyonelliğe odaklanır; kalite nitelikleri ya her hikâyenin kabul kriterlerine, ya ekibin Bitti Tanımı'na (Definition of Done) ya da ayrı teknik iş kalemlerine işlenmelidir.
• Çelişkiyi görmezden gelmek: En yüksek güvenlik seviyesi ile en akıcı kullanıcı deneyimi aynı anda istenebilir; bu dengenin paydaşlarla açıkça önceliklendirilmesi gerekir.
• Tasarımı gereksinim gibi yazmak: "Veriler belirli bir veritabanı ürününde tutulmalıdır" bir gereksinim değil, gerekçesi olmadıkça bir çözüm tercihidir.

Mindset programlarında gereksinim yazımını nerede çalışırsınız?

Gereksinim Analistliği Sertifika Programı gereksinim mühendisliğine giriş, gereksinim çerçeveleri ve standartlar, bilgi toplama teknikleri, gereksinim yazımı ve dokümantasyon kalitesi, çevik gereksinimler, doğrulama ve onaylama ile izlenebilirlik ve değişiklik yönetimi modüllerini içerir.

Gereksinim Yönetimi ve İzlenebilirlik (Savunma Projeleri) eğitimi ihtiyaç çıkarma ve analiz, gereksinim yazımı, ayrıştırma ve tahsis, izlenebilirlik ve temel çizgi ile değişiklik etki analizi konularını işler. Güvenlik niteliklerine odaklanmak isteyenler için Güvenlik Gereksinimleri ve Güvenli Tasarım İnceleme eğitimi tamamlayıcı bir seçenektir.