30 saniyelik özet

Functional Requirement, yani fonksiyonel gereksinim, sistemin belirli bir olay, girdi veya kullanıcı eylemi karşısında hangi davranışı sağlayacağını tanımlar. Hesaplama yapmak, veriyi doğrulamak, kayıt oluşturmak ve sonuç bildirmek buna örnektir. İyi bir ifade; koşulu, beklenen davranışı ve gözlenebilir sonucu açıklar. Gereken hata ve istisna yolları da tanımlanır. Bir özellik başlığı tek başına yeterli değildir. İş ihtiyacı, geliştirilebilecek ve doğrulanabilecek davranışlara ayrılmalıdır.

Neden önemli?

Bir danışmanlık platformunda “zaman kayıtlarından otomatik fatura oluştur” talebi ilk bakışta açık görünebilir. Ancak hangi kayıtların kullanılacağı, hangi ücretin uygulanacağı ve eksik bilgi bulunduğunda ne yapılacağı belirtilmemişse ekipler farklı çözümler düşünebilir. Aynı talep, farklı uygulama davranışlarıyla karşılanabilir.

Geliştirme ekibi bütün zaman kayıtlarını toplayabilir. Operasyon yalnızca onaylanmış kayıtların kullanılmasını bekleyebilir. Finans, sözleşmeye göre faturalandırılmayacak işleri dışarıda tutmak isteyebilir. Bu ayrımlar geliştirme sırasında ortaya çıkarsa tamamlanmış işin yeniden düzenlenmesi gerekebilir. Eksiklik, çoğu zaman özellik adında değil davranış tanımındadır.

Junior bir iş analisti için fonksiyonel gereksinim, araştırdığı ihtiyacı uygulanabilir bir ifadeye dönüştürme becerisidir. Yönetici için ise kapsam ve riskin görünür olmasıdır. “Otomasyon yapılacak” cümlesinin altında hangi işler bulunduğu açıklanmadığında maliyet, bağımlılık ve operasyonel hazırlık da eksik değerlendirilir.

Endüstri mühendisliği açısından girdi, işlem ve çıktı arasındaki ilişki önemlidir. Ancak sistemler yalnızca sorunsuz akışla çalışmaz. Aynı talep tekrar gelebilir, veri geç ulaşabilir veya bir işlem yarıda kalabilir. Bu koşulların beklenen davranışı nasıl değiştirdiği de gereksinimlerde ele alınmalıdır.

Terim nedir?

Fonksiyonel gereksinim, çözümün sağlaması gereken işlevi veya davranışı belirtir. Örneğin “Geçerli indirim kodu girildiğinde sistem, uygun ürünlere ilgili indirimi uygulamalı ve güncellenmiş toplamı göstermelidir” ifadesi işlev tanımlar. Hangi kodun geçerli sayıldığı ve hangi ürünlerin uygun olduğu ise ilgili iş kurallarıyla açıklanır.

İş gereksinimi, değişimin işletme açısından neden gerekli olduğunu anlatır. İş kuralı, kararın hangi koşullarla verileceğini belirler. Fonksiyonel gereksinim, bu ihtiyacı ve kuralları çözümün davranışına bağlar. Aynı kural birden fazla işlevde kullanılabilir; kuralların her yerde farklı kelimelerle yeniden yazılması tutarsızlık yaratabilir.

Fonksiyonel olmayan gereksinimler ise performans, güvenilirlik veya kullanılabilirlik gibi kalite beklentilerini tanımlar. “Sistem toplamı hesaplamalı” bir davranıştır; bu davranışın hangi yük altında hangi sürede tamamlanacağı ayrı bir kalite koşuludur. Ayrım her konuda keskin değildir; güvenlik gibi alanlar hem işlev hem kalite gereksinimleri içerebilir.

Gereksinimin uygulanabilir olması için bağlam gerekir. Yetkili rol, tetikleyici olay, ön koşullar, kullanılan veri ve beklenen sonuç açıklanmalıdır. Bunların hepsini aynı cümleye sıkıştırmak zorunlu değildir. İlgili kurallara ve veri tanımlarına bağlantı verilebilir. Önemli olan geliştiricinin ve test ekibinin eksik davranışı tahminle tamamlamak zorunda kalmamasıdır.

Hata davranışı da sistemin ne yapacağını anlatır. Eksik ücret bilgisi bulunduğunda taslak oluşturulmaması ve sorumluya hangi kaydın eksik olduğunun gösterilmesi bir fonksiyonel davranıştır. “Hatalar yönetilecek” ifadesi bunun yerini tutmaz. Hangi durumda hangi sonucun oluşacağı belirli olmalıdır.

Gereksinim, gereksiz teknik tercih dayatmamalıdır. Belirli bir ürün veya veri tabanı kullanımı, gerçekten zorunlu bir kısıtsa ayrıca gerekçelendirilir. Kullanıcının ihtiyacını anlatırken uygulama yöntemini erken sabitlemek, daha uygun seçenekleri dışlayabilir. Buna karşılık doğrulanmış sistem sınırlarını belirtmemek de uygulanabilirliği belirsiz bırakır.

Gerçek vaka: Stripe’ta kullanım verisini kabul etmekle işlemek arasındaki fark

Stripe’ın kullanım bazlı faturalandırma yazısı, müşterinin kullanım olaylarının kabul edilmesi ve faturalama için işlenmesini anlatıyor. Yeni yaklaşımda kimlik ve giriş doğrulamasından geçen olaylar işlenmek üzere aktarılıyor. İşlemenin isteği kabul etme anında tamamlanmaması, sonradan oluşan hataların takip edilmesini gerekli kılmış.

Şirket bu ihtiyaca karşı işlemenin izlenebildiği bir panel ve doğrulama başarısızlıklarını bildiren mekanizmalar geliştirdiğini açıklıyor. Yazı ayrıca kullanım kayıtlarıyla fiyat değişikliklerinin eşleştirilmesini ve gecikmiş olayların ele alınmasını anlatıyor. Kullanımın kabul edilmesi, ücretinin doğru hesaplanmasıyla aynı aşama değil.

Bu vaka, bir iş modelinin birden fazla sistem davranışına ayrıldığını gösteriyor. Fonksiyonel gereksinim açısından yapılabilecek çıkarım; kabul, işleme, hesaplama ve hata bildiriminin ayrı ayrı açıklanması gerektiğidir. Kaynak Stripe’ın teknik tasarım anlatımıdır; şirketin resmî gereksinim belgesini veya bütün uygulama koşullarını yayımladığı anlamına gelmez.

Kaynak: Taras Mitran ve Karan Dhabalia, “How we built it: Usage-based billing”, Stripe, 28 Ocak 2025.

Varsayımsal örnek: Zaman kayıtlarından fatura taslağı oluşturmak

Bir danışmanlık şirketinin proje takibi uygulamasında, onaylanmış zaman kayıtlarından fatura taslağı hazırlanacağını düşünelim. İş ihtiyacı, hazırlama sırasında yapılan manuel aktarımı ve hataları azaltmak olsun. Taslak üretimi, faturanın kesinleştirilmesi veya gönderilmesiyle aynı işlem değildir.

Analist önce kayıtların seçilmesini tanımlar: Sistem, yetkili kullanıcının belirlediği proje ve dönem için onaylanmış, faturalandırılabilir ve daha önce faturalanmamış zaman kayıtlarını belirlemelidir. “Onaylanmış” ve “faturalanmış” durumlarının anlamları ilgili iş kurallarıyla doğrulanır. Veri tanımları, ekran etiketleriyle sınırlı bırakılmaz.

Hesaplama ayrı bir davranıştır. Sistem, uygun kayıtlara sözleşmeden doğrulanan ücretleri uygulamalı ve taslakta tutarın hangi kayıtlara dayandığını gösterebilmelidir. Ücretin hangi tarihteki sürümünün kullanılacağı da belirlenmelidir. Bugünkü ücretin geçmiş döneme kendiliğinden uygulanacağı varsayılmaz.

Eksik bilgi yolu açıkça yazılır. Geçerli ücret bulunamadığında sistemin nasıl davranacağı iş sahibiyle kararlaştırılır. Bu örnekte taslağın oluşturulmadığını ve kullanıcıya eksik kaydın gösterildiğini varsayalım. Bu bir tasarım kararıdır; bütün işletmeler için geçerli faturalama kuralı değildir.

Tekrar talebi de araştırılır. Kullanıcı aynı işlemi yeniden başlattığında aynı kayıtların ikinci kez ücretlendirilmemesi gerekir. Ancak taslakta bulunmak ile kesin faturaya dahil olmak farklı durumlar olabilir. Analist, kayıtların hangi aşamada hangi işlemlere uygun olduğunu ilgili rollerle netleştirir.

Kabul senaryoları, yani beklenen davranışın doğrulanacağı örnekler hazırlanır. Uygun kayıt, onaylanmamış kayıt, eksik ücret ve tekrar talebi değerlendirilir. İlgili kayıtların ve sonuçların doğru olması kontrol edilir. Sistemin beklenen yükte çalışma süresi ise ayrıca tanımlanan kalite koşullarıyla sınanır.

Yaygın üç hata

  1. Özellik başlığını gereksinim kabul etmek. “Otomatik faturalama” bir iş alanını anlatır; uygulanacak davranışları açıklamaz. Seçim, hesaplama, kayıt oluşturma ve hata bildirimini gerektiği kadar ayırın. Her davranışın iş ihtiyacına katkısı ve sonucu anlaşılmalıdır.
  2. Tek ifadede bağımsız davranışları birleştirmek. Uzun bir cümle, gereksinimin hangi parçasının tamamlandığını veya değiştiğini izlemeyi zorlaştırabilir. Ayrı karar veya doğrulama gerektiren davranışları ayırın. Bağlantılarını koruyun; parçalamak, sürecin bütününü gözden kaçırmaya yol açmamalıdır.
  3. Hata ve sınır durumlarını geliştirme ekibine bırakmak. Teknik ekip uygulanabilir seçenekler sunabilir; ancak iş sonucunu etkileyen kararların sahibi açık olmalıdır. Eksik veri, yetkisiz işlem ve tekrar talebi gibi durumlarda beklenen sonuç kararlaştırılmalıdır. Sessiz varsayımlar, sonradan operasyonel soruna dönüşebilir.

Mini uygulama: Fonksiyonel gereksinim kartı

Bir iş ihtiyacından tek bir davranış seçin ve aşağıdaki alanları doldurun. Bilinmeyen iş kararlarını açık soru olarak kaydedin.

Gereksinim kimliği ve adı
—
İş ihtiyacı
Hangi amaca katkı sağlıyor?
Aktör veya kaynak
İşlemi kim ya da hangi olay başlatıyor?
Ön koşul
Başlamadan önce ne doğru olmalı?
Girdi
Hangi bilgi gerekiyor?
Beklenen davranış
Sistem hangi işlemi yapmalı?
İş kuralları
Hangi karar koşulları uygulanmalı?
Sonuç
Hangi kayıt veya durum değişmeli?
Hata yolu
İşlem tamamlanamazsa ne olmalı?
Doğrulama örneği
Hangi girdide hangi sonuç bekleniyor?

Kartı bir geliştirici ve test sorumlusuyla inceleyin. Aynı örnekte farklı sonuçlar bekleniyorsa ifade henüz ortak anlayış sağlamıyor olabilir. Gereksinimin değeri ayrıntı miktarında değil, gerekli davranışın tahmine gerek kalmadan anlaşılabilmesindedir.

İlgili terimler

Business Requirement, Business Rule, Requirements Elicitation, Non-Functional Requirement, Use Case, User Story, Acceptance Criteria, Data Mapping ve Data Dictionary, API Specification / API Contract, Requirements Traceability Matrix, Scope ve Out of Scope