Yazılım Şartnamesi Nasıl Hazırlanır? 10 Bölümlü Şablon

Yazılım projelerinde en pahalı cümle "biz öyle anlamamıştık"tır. Şartname olmadan alınan teklifler karşılaştırılamaz, çünkü her tedarikçi farklı bir kapsamı fiyatlar; proje başladıktan sonra da kapsam tartışması bitene kadar sürer. İyi bir şartname otuz sayfalık bir belge olmak zorunda değildir; on bölümlü, test edilebilir cümlelerden oluşan on sayfalık bir belge çoğu kurumsal proje için yeterlidir.

Bu yazıda o on bölümü, gereksinim yazma kurallarını, bir kullanıcı hikâyesi ve kabul kriteri örneğini ve teklife çıkmadan önce uygulanacak kontrol listesini paylaşıyoruz. Amaç, teklif isteyen kurumun kendi başına yazabileceği bir şablon vermektir.

Şartname nedir, ne değildir?

Şartname, yazılımın ne yapması ve neden gerektiğini anlatır; nasıl yapılacağını anlatmaz. Veritabanı şeması, framework seçimi, ekran tasarımı teklif veren tarafın işidir. Kurum yalnızca kısıtlarını yazar: "mevcut SAP ile entegre olacak", "verimiz Türkiye'de tutulacak", "kurumsal kimlik doğrulama Active Directory üzerinden". Teknik çözümü şartnameye yazmak, tedarikçinin daha iyi bir çözüm önermesini engeller ve yanlış çözümün sorumluluğunu kuruma yükler.

On bölümlü şablon

Gereksinim yazma kuralları

Bir gereksinim, iki kişinin farklı anlayamayacağı ve bir testle doğrulanabilecek tek cümledir. Dört kural:

1. Tek cümle, tek gereksinim. "ve" ile bağlanan iki istek iki gereksinimdir.

2. Ölçülebilir ol. "Hızlı" değil, "500 kayıtlık liste 2 saniyenin altında açılır".

3. Kim, ne, neden. "Depo sorumlusu, sevkiyat öncesi stok yetersizliğini görmek için, siparişi onaylarken eksik kalemleri uyarı olarak görür."

4. Öncelik ver. Must (olmazsa olmaz), Should (önemli), Could (iyi olur), Won't (bu fazda değil). Her şey "Must" olan şartname önceliksizdir.

Kullanıcı hikâyesi ve kabul kriteri örneği

Hikâye US-014 (Must)
Bayi yöneticisi olarak, kredi limitini aşan siparişlerin onaya düşmesini istiyorum,
böylece tahsilat riski taşıyan siparişler kontrolsüz sevk edilmesin.

Kabul kriterleri
1. Sipariş tutarı + açık bakiye, bayi kredi limitini aşıyorsa sipariş "Onay Bekliyor" durumuna geçer.
2. Bölge müdürü onayladığında sipariş normal akışa döner; reddettiğinde bayiye gerekçeli bildirim gider.
3. Kredi limiti SAP'den günlük alınır; SAP'ye ulaşılamazsa son bilinen limit ve "güncel değil" uyarısı kullanılır.
4. Onay bekleyen siparişler 48 saat içinde işlem görmezse bölge müdürüne hatırlatma gider.

Bu biçim, tedarikçinin fiyatlamasını, geliştiricinin tasarımını ve test ekibinin senaryosunu aynı metinden türetmesini sağlar. Kabul testi, kriterlerin tek tek işaretlenmesidir; "beğendik/beğenmedik" tartışması ortadan kalkar.

Fonksiyonel olmayan gereksinimlerde asgari liste

• Performans: eşzamanlı kullanıcı sayısı, kritik ekranlar için yanıt süresi hedefi, veri hacmi (kayıt sayısı, yıllık artış).

• Güvenlik ve kimlik: kimlik doğrulama yöntemi, rol modeli, şifre/oturum politikası, sızma testi beklentisi.

• KVKK ve uyum: kişisel veri envanteri, saklama süreleri, silme/anonimleştirme, erişim logu, verinin tutulacağı ülke.

• Erişilebilirlik ve cihaz: desteklenen tarayıcılar, mobil kullanım, çevrimdışı ihtiyaç.

• Süreklilik: yedekleme, kabul edilebilir kesinti süresi, bakım penceresi.

• Dil ve yerelleşme: arayüz dilleri, para birimi, tarih formatları.

Sık yapılan altı hata

1. Çözümü yazmak: "Mikroservis mimarisinde, React ile" — bunlar kısıt değilse yazılmamalıdır.

2. Mevcut ekranı tarif etmek: "Şu anki programdaki gibi olsun" cümlesi, eski sistemin hatalarını da devralır.

3. Kapsam dışı yazmamak: Muhasebe entegrasyonu kapsam dışıysa yazılmalıdır; yoksa teklifte "dahil" sanılır.

4. Veri göçünü unutmak: Eski verinin taşınması ayrı bir gereksinimdir ve genellikle projenin en zahmetli işidir.

5. Kabul kriterini yazmamak: Kabulü tanımsız proje, teslimi tanımsız projedir.

6. Tek kişinin yazması: Süreci yaşayan kullanıcılar okumadan şartname tamamlanmış sayılmaz.

Teklife çıkmadan önce kontrol listesi

• İş hedefi ölçülebilir bir cümleyle yazıldı.

• Kapsam ve kapsam dışı listeleri ayrı ayrı var.

• Hedef süreç akışı istisnalarıyla çizildi; kullanıcılar tarafından onaylandı.

• Her fonksiyonel gereksinim numaralı, tek cümle, öncelikli.

• Entegre olacak sistemler, veri nesneleri ve veri yönleri tablo halinde.

• Fonksiyonel olmayan gereksinimler asgari listeyi karşılıyor.

• Kritik tarihlerin gerekçesi ve bütçe aralığı belirtildi.

• Kabul kriterleri ve kabul testi sorumlusu tanımlı.

• Kaynak kod mülkiyeti, dokümantasyon, eğitim ve bakım beklentisi yazılı.

• Ürün sahibi atandı ve karar süresi taahhüdü var.

Sık sorulan sorular

Şartname ne kadar uzun olmalı?

Kapsam kadar. Tek modüllü bir uygulama için 5–8 sayfa, çok rollü entegrasyonlu bir platform için 15–25 sayfa tipiktir. Uzunluk değil, her cümlenin test edilebilir olması önemlidir.

Şartnameyi tedarikçi mi yazmalı?

İlk taslağı kurum yazmalı; tedarikçi keşif aşamasında sorularla netleştirir ve gereksinim analizini derinleştirir. Şartnameyi tamamen tedarikçiye bırakmak, kapsamın tedarikçinin çıkarına göre şekillenmesi riskini taşır.

Agile projede şartname gerekli mi?

Evet, biçimi değişir: uzun bir gereksinim listesi yerine hedef, kapsam, kısıtlar ve önceliklendirilmiş bir hikâye listesi. Kabul kriterleri sprint sprint yazılsa da amaç ve kapsam dışı bölümleri baştan gerekir.

Sonuç

İyi bir şartname; ne ve neden sorularını ölçülebilir cümlelerle cevaplayan, kapsam dışını açıkça yazan, entegrasyon ve veri göçünü tablolaştıran ve her gereksinimi kabul kriterine bağlayan bir belgedir. Bu belge teklifleri karşılaştırılabilir, projeyi ölçülebilir, teslimi tartışmasız kılar.

Şartnamenizi birlikte hazırlamak ya da mevcut taslağınızı keşif toplantısında gözden geçirmek için kurumsal uygulama geliştirme sürecimize göz atabilirsiniz. Keşif görüşmesi ve ilk tahmin ücretsizdir.