Spesifikasyon: Ürün oluşturma kılavuzu

Kerem Aydın·8 Temmuz 2026·⏱4 dk

Spesifikasyon, bir ürünün tam olarak nasıl çalışması gerektiğini, hangi parametrelere sahip olduğunu ve sonucun nasıl doğrulanacağını açıklayan detaylı bir teknik belgedir. Gereksinimler "ne yapılması gerektiğini" söylerken, spesifikasyon "bunun nasıl uygulanacağı" sorusuna cevap verir. IT ve mühendislik alanında bu belge, belirsizlikleri ortadan kaldıran geliştiriciler, test uzmanları ve mühendisler için ana referans noktasıdır.

Spesifikasyon olmadan ekip, teknik olarak çalışan ancak hız, güvenlik veya uyumluluk açısından beklentileri karşılamayan bir ürün riskiyle karşılaşır.

Ana fikir: Spesifikasyon, müşterinin soyut isteklerini ölçülebilir teknik parametrelere (sayılar, protokoller, standartlar) dönüştürür.

Spesifikasyon gereksinimlerden nasıl farklıdır?

Bu kavramlar sıkça karıştırılır, ancak aralarında önemli bir ayrım vardır:

Özellik	Gereksinimler (Requirements)	Spesifikasyon (Specification)
Seviye	İş seviyesi ("Ne istiyoruz?")	Teknik seviye ("Nasıl yapacağız?")
Hedef Kitle	Müşteri, ürün yöneticisi	Geliştiriciler, mühendisler, QA
İfade Şekli	"Site hızlı yüklenmeli"	"1000 RPS'de API yanıt süresi ≤ 200 ms"
Esneklik	Tartışma sürecinde değişebilir	Somut çözümleri ve kısıtlamaları sabitler

Gereksinimler hedefi belirler, spesifikasyon ise buna ulaşmak için bir plan sunar.

IT alanındaki spesifikasyon örnekleri

Yazılım geliştirmede spesifikasyon, tüm ürünü veya yalnızca bir bölümünü (örneğin API) kapsayabilir.

1. Web servisi spesifikasyonu (Backend)

Bir kimlik doğrulama servisi için belge şunları içerecektir:

Protokol: HTTPS üzerinden REST API.
Metotlar: POST /login, POST /refresh-token.
Veri formatı: JSON. email alanı regex ile doğrulanmalı, password yalnızca hash'lenmiş şekilde (bcrypt) iletilmelidir.
Performans: Sunucu, saniyede 500 isteği 100 ms'den fazla gecikme olmadan (95. yüzdelik dilim) işlemelidir.
Güvenlik: TLS 1.3 kullanımı, brute-force saldırılarına karşı koruma (5 başarısız denemeden sonra engelleme).

2. Mobil uygulama spesifikasyonu

Burada vurgu ortam ve kaynaklar üzerinedir:

OS Desteği: Android 12+, iOS 16+.
Çevrimdışı çalışma: Son 50 işlemin yerel olarak önbelleğe alınması (SQLite/Realm). Ağ bağlantısı kurulduğunda senkronizasyon.
Bellek tüketimi: Uygulama aktif modda RAM'de 150 MB'tan fazla yer kaplamamalıdır.
Arayüz: Material Design 3 ve Human Interface Guidelines kılavuzlarına uygunluk.

İpucu: İyi bir spesifikasyon her zaman "Sınır durumları" bölümünü içerir. Örneğin, ödeme sırasında internet kesilirse ne olur? Belge bu soruya net bir cevap vermelidir.

"Donanım" ve ev aletlerinden örnekler

Mühendislikte spesifikasyon, cihazın fiziksel ve elektriksel özelliklerini tanımlayan bir kimlik belgesidir.

Akıllı telefon veya dizüstü bilgisayar

Ekran: 6.1" çapraz, OLED tipi, 1000 nite kadar parlaklık, 120 Hz yenileme hızı.
Güç: 4000 mAh pil, PD 3.0 hızlı şarj desteği (25 W'a kadar).
Gövde: IP68 koruma derecesi (30 dakika boyunca 1.5 m derinliğe daldırma).

Endüstriyel sensör

Ölçüm aralığı: Sıcaklık -40°C ile +85°C arasında.
Hassasiyet: ±0.5°C.
Bağlantı arayüzü: RS-485, Modbus RTU protokolü.
Güç kaynağı: 12–24 V DC.

Bu tür belgeler, mühendislerin cihazın belirli bir görev için uygun olup olmadığını "deneme yanılma" testlerine başvurmadan hemen anlamalarını sağlar.

İdeal bir spesifikasyonun yapısı

Belgenin "raflarda tozlanmak" yerine faydalı olması için aşağıdaki plana göre oluşturulmalıdır:

Giriş ve amaçlar: Ürünün hangi sorunu çözdüğüne dair kısa bilgi.
Genel hükümler: Terimler, kısaltmalar, standartlara referanslar (GOST, ISO, RFC).
Fonksiyonel gereksinimler: Her bir fonksiyonun detaylı açıklaması.
- Girdi verileri: Sisteme ne veriliyor?
- Mantık: Sistem verilerle ne yapıyor?
- Çıktı verileri: Hangi sonuç döndürülüyor?
Fonksiyonel olmayan gereksinimler:
- Performans (hız, yük).
- Güvenlik (şifreleme, erişimler).
- Güvenilirlik (arıza arasındaki çalışma süresi, yedekleme).
Arayüzler ve entegrasyonlar: Diğer sistemlerle etkileşim şemaları (API, dosya formatları).
Kabul kriterleri: İşin tamamlandığının kabul edildiği koşulların net listesi (örneğin, "tüm otomatik testler geçti", "kritik hata yok").

Hazırlarken yapılan yaygın hatalar

Spesifikasyonunuzun işe yaraması için şu tuzaklardan kaçının:

Belirsiz ifadeler. "Hızlı", "kolay", "güvenilir" gibi kelimeler kabul edilemez. Bunları sayılarla değiştirin: "yüklenme < 2 sn", "arayüz en fazla 3 tıklama gerektirir".
Versiyon kontrolünün olmaması. Spesifikasyon değişir. Geliştiricilerin eski verilere göre çalışmaması için belge versiyonunu ve değişiklik tarihini mutlaka belirtin.
Kısıtlamaların göz ardı edilmesi. Yalnızca olacak olanlardan bahsetmeyin. Olmayacak olanları (scope dışı) belirtin. Bu, sonsuz revizyonlardan kurtaracaktır.
Detaylarla aşırı yükleme. Her kod satırını açıklamaya gerek yok. Sistemin davranışını ve mimari kararları açıklayın.

Tehlike: Spesifikasyonu yalnızca müşteriyle onaylamak. Eğer teknik uygulayıcılar (geliştiriciler/mühendisler) belgeyi incelememişse, tanımlananların verilen süre veya bütçe içinde gerçekleştirilememesi riski yüksektir.

SSS

Spesifikasyon olmadan geliştirmeye başlanabilir mi? Başlanabilir, ancak bu yeniden düzenlemeler nedeniyle proje maliyetinin artmasına yol açar. Küçük görevler için tracker'daki bir ticket yeterlidir, karmaşık sistemler için belge zorunludur.

Spesifikasyonu kim yazar? Genellikle bu, sistem analisti, teknik lider (Tech Lead) ve mimarın ortak çalışmasıdır. Nihai versiyonu müşteri onaylar.

Spesifikasyon ne sıklıkla güncellenmelidir? Gereksinimlerde veya mimaride herhangi bir değişiklik olduğunda. Güncel spesifikasyon arşivlik bir kağıt değil, yaşayan bir belgedir.

Spesifikasyon kodla çelişiyorsa ne yapılmalı? Her zaman öncelik onaylanmış belgededir. Kod farklı yazılmışsa, bu ya koddaki bir hatadır ya da spesifikasyonda değişiklik yapılıp bunların yeniden onaylanması gerekir.