Yazılım teknik şartnamesi nasıl hazırlanır?

İyi bir yazılım teknik şartnamesi teknolojiyi değil işi anlatır: kullanıcılar, iş akışları, öncelikli özellikler, entegrasyonlar ve her teslimin kabul kriteri.

Şartname neyi anlatmalı

Teknik şartname, teklif isteyeceğiniz firmaların aynı işi fiyatlamasını sağlayan belgedir. Şu konuların her birine en az birkaç cümle ayırın:

• Kullanıcılar ve roller: sistemi kimler kullanacak, kim neyi görecek ve neyi değiştirebilecek.
• İş akışları: her iş nasıl başlıyor, hangi adımlardan geçiyor, nasıl bitiyor.
• Öncelik: ilk sürümde mutlaka bulunması gerekenler ve sonraya kalabilecekler.
• Veri ve veri taşıma: Excel dosyalarından ya da eski sistemden hangi kayıtların, kaç adet aktarılacağı ve bunları kimin temizleyeceği.
• Entegrasyonlar: hangi sistemle, hangi yönde, hangi veri; örneğin cari ve stok kartlarını LOGO ERP'den okumak ya da kabul edilen teklifi LOGO ERP'ye satış siparişi olarak yazmak.
• Platformlar ve diller: web, iOS, Android ya da masaüstü; arayüzün hangi dillerde olacağı.
• Kabul kriterleri: her teslimin hangi testle “tamam” sayılacağı.
• Teslim ve sahiplik: kodun, veritabanının ve hesapların kime ait olacağı.
• Destek: yayından sonra hata düzeltme ve yeni istekler için ne beklediğiniz.

Bütçenizin aşılamayacak bir üst sınırı varsa onu da yazabilirsiniz; firma kapsamı bu sınıra göre önerebilir.

Örnek başlıklar

Aşağıdaki başlıklar, bir yazılım geliştirme teknik şartnamesi için örnek bir iskelettir; kopyalayıp kendi işinize göre doldurabilirsiniz. Her başlığın altına kısa ve somut cümleler yazın; uzunluktan çok açıklık önemlidir.

1. Şirket ve amaç: ne iş yaptığınız ve bu yazılımın hangi sorunu çözeceği.
2. Bugünkü durum: işin bugün nasıl yapıldığı; kullanılan Excel dosyaları, formlar ve programlar.
3. Kullanıcılar ve roller: rol adı, yaklaşık kişi sayısı, yetkiler.
4. İş akışları: her akış için başlangıç, adımlar, sonuç ve istisnalar.
5. İlk sürümün kapsamı: ilk sürümde şart olanlar ve sonraki sürümlere bırakılanlar.
6. Veriler: aktarılacak kayıtlar, kaynakları, adetleri ve temizleme sorumlusu.
7. Entegrasyonlar: sistemin adı, verinin yönü, sıklık ve bağlantı koptuğunda ne olacağı.
8. Kişisel veriler: hangi kişisel verilerin işleneceği ve KVKK açısından veri sorumlusu ile veri işleyenin kim olacağı.
9. Platformlar, diller ve cihazlar: tarayıcılar, telefonlar, tabletler ve arayüz dilleri.
10. Kabul kriterleri ve test verisi: her teslim için ölçülebilir koşullar ve hangi veriyle test edileceği.
11. Teslim, sahiplik ve hesaplar: kod deposu, veritabanı, barındırma ve alan adı.
12. Destek beklentisi: yayından sonraki ilk dönem ve sonrası.
13. Takvim ve karar süreci: teklif için son tarih, soruların kime sorulacağı ve seçimin nasıl yapılacağı.
14. Teklifte beklenenler: firmaların cevabında görmek istediğiniz başlıklar (aşağıda).

Özellik listesi yerine iş akışları

“Müşteri modülü, rapor modülü, kullanıcı yönetimi” gibi bir liste her firmaya başka bir şey anlatır. Aynı işi adım adım bir akış olarak yazdığınızda yanlış anlaşılma azalır. Örneğin bir teklif akışı şöyle yazılabilir:

1. Satış temsilcisi müşteriyi seçer; ekranda müşterinin kredi limiti ve risk puanı görünür.
2. Teklif satırlarını ekler; fiyatlar müşteriye özel fiyat listesinden gelir.
3. Teklif PDF olarak dışa aktarılır.
4. Kabul edilen teklif, muhasebe ya da ERP sistemine satış siparişi olarak geçer.

Bu örnek, SPSTARPLAST'ın ERP'sindeki teklif ekranından ve LOGO ERP entegrasyonundan alındı. Her adımın yanına istisnaları da yazın: kredi limiti aşılırsa ne olur, fiyat listesinde olmayan bir ürün nasıl fiyatlanır, o gün bitmeyen iş ne olur?

Kabul kriteri nasıl yazılır

Kabul kriteri, bir teslimin “tamam” sayılması için gereken ve test edilebilen koşuldur. “Kullanıcı dostu olmalı” bir kabul kriteri değildir. “Öğretmen, yapay zekânın verdiği kararı değiştirebilir ve öğretmenin kararı geçerli olur” ise bir kabul kriteridir. Mayıs 2026'dan beri Özel Beşiktaş Erkan Ulu Ortaokulu'nda kullanılan Dijital Yanlış Defteri'nde öğretmenin kararı her zaman geçerlidir.

İyi bir kabul kriterinde dört şey bulunur: hangi ekran ya da işlem, hangi veri, beklenen sonuç ve testi kimin yapacağı. Yapay zekâ ya da görüntü işleme içeren işlerde ölçümün hangi belgelerle yapılacağını da yazın; bu belgeler eğitimde kullanılmamış olmalıdır. Otocropper'ın modeli böyle ölçüldü: eğitimde hiç kullanılmamış 238 sayfalık bir kitapta bir soru, ancak bulunan kutu doğru kutuyla neredeyse tamamen örtüştüğünde (IoU ≥ 0,9) doğru sayıldı. Sonuç: kitaptaki soruların %97,1'i bulundu (duyarlılık) ve bulunan kutuların %96,9'u doğruydu (kesinlik).

Ölçümü ve sürüm kontrolünü ayrı yazın. Otocropper, 1.0.2 sürümünden önce okuldan gelen 20 PDF dosyasında, toplam 4.813 sayfada da denendi; bu bir doğruluk ölçümü değil, yayından önce yapılan bir sürüm kontrolüdür.

Firmalardan ne istemelisiniz

Şartnamenin sonuna, tekliflerde görmek istediğiniz başlıkları yazın. Böylece teklifleri yan yana koyabilirsiniz:

• Yazılı kapsam ve firmanın varsayımları.
• Kilometre taşları ve her birinin kabul kriteri.
• Fiyat modeli: sabit fiyat mı, adam/saat mi? Farkları fiyat modelleri rehberinde.
• İşin bir bölümünün başka bir firmaya verilip verilmeyeceği.
• Açıp inceleyebileceğiniz, yayında olan işler.
• Teslimde kodun, veritabanının ve hesapların kime geçeceği; ayrıntılar kaynak kod devri rehberinde.
• Destek koşulları ve süresi.
• Sözleşmeyi hangi şirketin imzalayacağı ve hangi hukukun uygulanacağı; bkz. sözleşmede dikkat edilmesi gerekenler.

Teklifler geldiğinde önce kapsamların aynı olup olmadığına bakın, fiyatı ancak bundan sonra karşılaştırın. Bir teklifin kalemlerini nasıl okuyacağınızı yazılım maliyeti hesabı rehberinde anlattık.

Şartnamede sık yapılan hatalar

• Teknolojiyi baştan şart koşmak. Belirli bir dil ya da çerçeve gerçekten gerekmiyorsa, örneğin mevcut bir sisteme uymak için, seçimi teklif veren firmaya bırakın ve gerekçesini isteyin.
• Ekran çizimlerini şartname sanmak. Çizimler iş kurallarını, istisnaları ve yetkileri anlatmaz.
• Veri taşımayı unutmak. Eski kayıtların aktarılması teklifte ayrı bir kalem olarak görünmelidir.
• Entegrasyonları sonraya bırakmak. Muhasebe ya da ERP bağlantısı şartnamede yoksa tekliflerde de yer almaz.
• Sıfatla yazmak. “Hızlı”, “güvenli” ya da “kolay” yerine ölçülebilir bir koşul yazın.
• İşi bugün yürüten kişiyle konuşmamak. Bu kişinin bildikleri yazıya geçmezse istisnalar şartnamede yer almaz.

RFP, teknik şartname ve gereksinim dokümanı arasındaki fark

“RFP nedir, gereksinim dokümanı nedir?” sorularının kısa cevabı aşağıda. Bu üç terim birbirine yakındır ama aynı belgeyi anlatmaz:

• RFP (request for proposal, teklif çağrısı): firmalardan teklif istediğiniz belgenin bütünüdür; teknik şartnameyi, teklif son tarihini ve seçimin nasıl yapılacağını içerir.
• Teknik şartname: yapılacak işin kendisini anlatır: kullanıcılar, iş akışları, veriler, entegrasyonlar ve kabul kriterleri.
• Yazılım gereksinim dokümanı: çoğunlukla firma seçildikten sonra, analiz sırasında yazılan ayrıntılı belgedir; her ekranın ve kuralın davranışını tek tek tarif eder.

RFI (request for information) firmalar hakkında bilgi toplamak, RFQ (request for quotation) ise kapsamı belli bir iş için yalnızca fiyat almak için kullanılır. Bir yazılım projesinde teklif aşamasında RFP ile teknik şartname çoğu zaman yeter; gereksinim dokümanını seçtiğiniz firmayla birlikte yazarsınız.

Kamu ihalesindeki teknik şartname başka bir belgedir

Türkiye'de “teknik şartname” terimi kamu ihalelerinde de kullanılır. Kamu ihalelerindeki teknik şartnamenin temel kuralı Kamu İhale Kanunu'nun 12. maddesindedir:

Aynı maddeye göre kamu şartnamelerinde “Belli bir marka, model, patent, menşei, kaynak veya ürün belirtilemez”; standart bulunmaması gibi durumlarda ise “veya dengi” ifadesine yer verilmek şartıyla marka veya model belirtilebilir. Bu rehber şirketlerin kendi yazılım alımları içindir. Bir kamu ihalesine hazırlanıyorsanız kanunla birlikte ihale mevzuatının tamamına ve kurumunuzun ihale birimine başvurun.

Yazılı teklifimiz şartnameye nasıl cevap verir

Şartnamenizi aldıktan sonra 15 dakikalık ücretsiz bir ön görüşme yaparız. Görüşmenin ardından gönderdiğimiz yazılı teklifte kapsam, kilometre taşları, kabul kriterleri ve tek bir fiyat yer alır; bunun nasıl işlediğini yazılı kapsam ve sabit fiyatlı teklif sayfasında özetledik.

Ödeme üç parçadır: %30 işe başlarken, %40 ara teslimde, %30 iş tamamlandığında; ara teslimdeki ve tamamlanmadaki ödemeler, teklifteki kabul kriterlerine göre yapılan kontrole bağlıdır. Geliştirme boyunca her hafta çalışan bir sürümü kendiniz deneyebilirsiniz; kod deposu, veritabanı ve barındırma sizin adınıza açılan hesaplarda tutulur. Şirketinize özel bir sistem düşünüyorsanız özel yazılım geliştirme sayfasındaki işlere bakın.

İlgili hizmet

Yazılı teklif ve sabit fiyat: şartnamenize, ön görüşmeden sonra yazılı ve sabit fiyatlı bir teklifle cevap veririz.

İlgili rehberler

• Yazılım proje maliyeti nasıl hesaplanır?
• Yazılım geliştirme sözleşmesinde dikkat edilmesi gerekenler
• Sabit fiyat mı, adam/saat mi, yazılımcı kiralama mı?

Kaynaklar

• Kamu İhale Kanunu, 4734 (md. 12), mevzuat.gov.tr (PDF); 16 Ekim 2026 tarihinde kontrol edildi.