Teknik Şartname Nasıl Hazırlanır? Yazılım Projesinde Gereksinim Analizi Rehberi

Teknik şartname, yaptırmak istediğiniz yazılımın ne yapacağını, kimin tarafından nasıl kullanılacağını ve hangi koşulları karşılaması gerektiğini yazılı hale getiren belgedir. İyi hazırlanmış bir şartname, teklif isteyeceğiniz firmaların aynı işi fiyatlamasını sağlar ve proje boyunca "bu da kapsamda mıydı" tartışmasını azaltır. Hazırlamak için yazılım bilmeniz gerekmez; işinizi, süreçlerinizi ve beklentinizi bilmeniz yeter.

Aşağıda gereksinim analizini adım adım anlatıyor, fonksiyonel ve fonksiyonel olmayan gereksinimleri örneklerle ayırıyor ve kendi projeniz için doldurabileceğiniz bir gereksinim listesi şablonu veriyoruz.

Teknik şartname nedir, ne işe yarar?

Yazılım projesinde teknik şartname, iş ihtiyacını yazılım ekibinin anlayacağı ve test edebileceği maddelere çevirir. Cevapladığı soru şudur: bu yazılım neyi, kim için, hangi koşulda yapacak? "Hangi programlama diliyle, hangi veritabanıyla yapılacak" sorusu ise çoğu zaman yazılım ekibine bırakılır. Mevcut bir sunucu, zorunlu bir entegrasyon ya da kurum içi bir güvenlik politikası gibi kısıtlar varsa onlar da şartnameye yazılır.

Terim kamu ihalelerinde de kullanılır; orada şartnamenin içeriği ve hazırlanma kuralları ihale mevzuatıyla belirlenir. Bu yazı, özel sektörde yaptırılan yazılım projelerine odaklanır.

Şartname üç aşamada işe yarar. Teklif aşamasında firmaların aynı kapsamı fiyatlamasını sağlar. Geliştirme sırasında ekibin başvurduğu ortak referans olur. Teslimde ise "iş bitti mi" sorusunun cevabı, şartnamedeki kabul kriterlerine bakılarak verilir.

Eksiksiz bir teknik şartnamede genellikle şu başlıklar bulunur:

• Projenin amacı ve çözülecek iş problemi
• Kullanıcılar, roller ve her rolün yetkileri
• Bugünkü süreç ve yazılımla kurulacak hedef süreç
• Fonksiyonel gereksinimler
• Fonksiyonel olmayan gereksinimler (performans, güvenlik, KVKK, cihaz desteği)
• Entegrasyonlar ve veri kaynakları
• Yeni sisteme taşınacak mevcut veriler
• Kapsam dışı bırakılan konular
• Kabul kriterleri: teslimde neyin, nasıl kontrol edileceği

İhtiyaç analizi ile gereksinim analizi arasındaki fark

İhtiyaç analizi "neden" sorusunu cevaplar: işletmenin hangi sorunu var, bu sorun neye mal oluyor, yazılım olmadan nasıl çözülebilirdi? Gereksinim analizi ise bu ihtiyacı doğrulanabilir maddelere böler: sistem şunu yapmalı, şu kullanıcı şunu görebilmeli, şu koşulda şu olmalı. Önce ihtiyaç analizi yapılır, gereksinim analizi onun üzerine kurulur. İhtiyaç netleşmeden yazılan gereksinimler, doğru tarif edilmiş ama yanlış problemi çözen bir yazılıma götürür.

Gereksinim analizi nasıl yapılır?

Yazılım gereksinim analizi tek bir toplantıda bitmez; birkaç tur görüşme, not ve düzeltmeyle olgunlaşır. Aşağıdaki sıra, teknik ekibi olmayan bir işletmenin de uygulayabileceği bir çerçevedir.

1. Amacı tek cümleyle yazın. "Satış ekibinin teklif hazırlarken Excel, e-posta ve telefon arasında kaybettiği zamanı ortadan kaldırmak" gibi. Bu cümle, ileride her özellik için "bu amaca hizmet ediyor mu" diye sormanızı sağlar.
2. Paydaşları listeleyin. Yazılımı kullanacak ekipler, raporları okuyacak yöneticiler, muhasebe, bilgi işlem, KVKK sorumlusu ve gerekiyorsa müşteriler ya da bayiler.
3. Her paydaş grubuyla ayrı görüşün. Yönetici ile sahadaki kullanıcı aynı süreci farklı anlatır. İkisini de dinlemeden yazılan şartname eksik kalır.
4. Bugünkü süreci haritalayın. İşin nerede başladığını, kimin elinden geçtiğini, nerede beklediğini ve hangi dosyada tutulduğunu adım adım çizin.
5. Hedef süreci çizin. Yazılım devreye girdiğinde aynı işin nasıl akacağını gösterin. Hangi adım kalkıyor, hangisi otomatikleşiyor, hangisi onaya bağlanıyor?
6. Gereksinimleri yazın ve sınıflandırın. Her maddeyi fonksiyonel ya da fonksiyonel olmayan olarak işaretleyin, kaynağını (kimin istediğini) not edin.
7. Önceliklendirin ve doğrulatın. Listeyi paydaşlara okutun, itirazları toplayın, son hali karar vericiye onaylatın.

Paydaş görüşmesinde sorulacak sorular

• Bu işi bugün hangi adımlarla yapıyorsunuz?
• En çok nerede bekliyor ya da zaman kaybediyorsunuz?
• Hangi bilgiyi bulmakta zorlanıyorsunuz, kime soruyorsunuz?
• Hangi raporu elle hazırlıyorsunuz, o raporu kim okuyor?
• Hangi hata işletmeye en pahalıya mal oluyor?
• Hangi programlarla ya da firmalarla veri alışverişi yapıyorsunuz?
• Bu işi yeni başlayan bir çalışana nasıl anlatırdınız?

Son soru, hiçbir yerde yazılı olmayan iş kurallarını ortaya çıkarır. "Şu müşteri grubuna onaysız iskonto verilmez" gibi kurallar genellikle bu cevaplarda saklıdır.

Fonksiyonel ve fonksiyonel olmayan gereksinimler

Fonksiyonel gereksinim, sistemin ne yapacağını anlatır. Fonksiyonel olmayan gereksinim ise bunu hangi koşullarda ve hangi kalitede yapacağını. Şartnamelerde en çok ihmal edilen ikinci gruptur; oysa teslimdeki pek çok tartışma, yazılmamış bu beklentilerden çıkar.

Fonksiyonel gereksinim örnekleri

• Satış temsilcisi, müşteri kartından teklif oluşturabilmeli ve teklifi PDF olarak gönderebilmeli.
• Belirlenen iskonto sınırının üzerindeki teklifler, satış müdürünün onayı olmadan gönderilememeli.
• Sipariş durumu "kargoya verildi" olduğunda müşteriye otomatik e-posta gitmeli.
• Yönetici, bölge ve temsilci bazında aylık satış raporunu Excel olarak indirebilmeli.

Her maddenin bir kullanıcıya ve bir sonuca bağlı olduğuna dikkat edin. "Teklif modülü olmalı" bir gereksinim değil, bir başlıktır.

Fonksiyonel olmayan gereksinimler

Başlık	Sorulacak soru	Şartnameye nasıl yazılır
Performans ve yük	Aynı anda kaç kişi kullanacak, yoğun dönem ne zaman?	Ay sonu kapanışında tüm satış ekibi aynı anda rapor alabilmeli.
Yetki ve güvenlik	Kim neyi görebilir, kim neyi değiştirebilir?	Bölge müdürü yalnız kendi bölgesindeki müşterileri görür.
KVKK ve kişisel veri	Hangi kişisel veriler işlenecek, kim erişecek, ne kadar saklanacak?	Silme talebi gelen müşterinin kişisel verileri anonimleştirilebilmeli.
Cihaz ve tarayıcı	Masaüstü mü, mobil mi, sahada internet var mı?	Saha ekibi telefondan sipariş girebilmeli.
Yedekleme ve süreklilik	Hangi veri kaybı kabul edilemez, sistem durursa ne olur?	Veriler düzenli yedeklenmeli, geri yükleme yöntemi belgelenmeli.
Entegrasyon	Hangi sistemlerle, hangi yönde veri alışverişi olacak?	Onaylanan sipariş muhasebe programına aktarılmalı.
Bakım ve devir	Yazılımı ileride kim geliştirecek, başka bir ekip devralabilir mi?	Kurulum adımları ve temel yapı, başka bir ekibin devralabileceği biçimde belgelenmeli.

Entegrasyon satırı çoğu projede başlı başına bir çalışma gerektirir. Hangi sistemin hangi veriyi ne sıklıkla göndereceğini netleştirmek için entegrasyon ihtiyaçlarını tanımlama yazımıza göz atabilirsiniz.

"Hızlı", "kullanıcı dostu" ya da "modern" gibi sıfatlar gereksinim değildir. Her biri ölçülebilir ya da gözlemlenebilir bir cümleye çevrilmelidir. "Hızlı" yerine hangi işlemin, hangi yoğunlukta, takılmadan tamamlanması gerektiğini yazın.

User story ile gereksinim yazmak

User story (kullanıcı hikâyesi), bir gereksinimi kullanıcının gözünden tek cümlede anlatma yöntemidir. Kalıbı basittir: "Bir [rol] olarak, [amaç] için [işlev] istiyorum." Bu kalıp sizi özelliği değil ihtiyacı yazmaya zorlar ve her maddede "bunu kim, neden istiyor" sorusunu cevaplatır.

Bir satış temsilcisi olarak, takip aramasını doğru zamanda yapabilmek için müşterinin gönderdiğim teklifi açıp açmadığını görmek istiyorum.

User story tek başına yetmez, kabul kriterleriyle tamamlanır. Kabul kriteri, hikâyenin ne zaman "tamamlandı" sayılacağını tarif eder. Yaygın yazım biçimi "şu durumda, şunu yaptığımda, şu olmalı" düzenidir:

• Teklif müşteriye e-postayla gönderildiğinde, teklif kaydında durum "gönderildi" olmalı.
• Müşteri teklif bağlantısını açtığında, temsilcinin ekranında açılma tarihi ve saati görünmeli.
• Teklif belirlenen süre içinde açılmazsa, temsilciye bir hatırlatma görevi oluşmalı.

İyi bir user story küçük, bağımsız ve test edilebilir olur. İngilizce INVEST kısaltmasıyla bilinen ölçütler de bunu söyler: bağımsız, üzerinde konuşulabilir, değerli, tahmin edilebilir, küçük ve test edilebilir. Bir hikâye birden fazla kullanıcı rolünü ya da birden fazla ekranı kapsıyorsa büyük olasılıkla bölünmelidir.

User story her şeyi anlatmaz. Performans, güvenlik ve KVKK gibi maddeleri hikâye kalıbına sokmaya çalışmak yerine yukarıdaki tabloda olduğu gibi ayrı yazmak daha okunaklıdır.

Gereksinimleri önceliklendirmek

Her gereksinim aynı önemde değildir ve hepsini ilk sürüme koymak hem takvimi hem bütçeyi zorlar. Yaygın yöntemlerden biri MoSCoW'dur; adını dört öncelik grubunun İngilizce baş harflerinden alır.

Öncelik	Anlamı	Örnek
Mutlaka (Must)	İlk sürüm bu olmadan kullanılamaz	Teklif oluşturma ve gönderme
Olmalı (Should)	Önemli, ama bir süre geçici çözümle idare edilebilir	Teklifin açıldığını görme
Olabilir (Could)	Değer katar, ertelenmesi işi durdurmaz	Teklif şablonlarında renk seçimi
Bu sürümde yok (Won't)	Bilinçli olarak kapsam dışı bırakıldı	Mobil uygulama

Son satır en az ilk üçü kadar değerlidir. "Bu sürümde yok" listesi yazılı olduğunda hem firma hem sizin ekibiniz neyin beklenmediğini bilir. Kapsam dışı olarak yazılmayan her konu, projenin ortasında "bu da dahil değil miydi" sorusu olarak geri döner.

Önceliklendirme bir karar noktası da yaratır. "Mutlaka" listesindeki maddelerin çoğu piyasadaki hazır bir üründe zaten varsa, sıfırdan geliştirmeden önce hazır yazılım ile özel yazılımı karşılaştırmak doğru olur. Özel yazılımın değeri genellikle hazır ürünlerin karşılamadığı iş kurallarında ortaya çıkar.

Gereksinim listesi şablonu

Aşağıdaki tabloyu bir hesap tablosuna taşıyıp kendi projeniz için doldurabilirsiniz. Her satır tek bir gereksinimdir.

No	Gereksinim	Tür	Öncelik	Kabul kriteri	Kaynak
G-01	Satış temsilcisi müşteri kartından teklif oluşturur	Fonksiyonel	Mutlaka	Teklif kaydedilir ve PDF olarak indirilebilir	Satış ekibi
G-02	İskonto sınırını aşan teklif müdür onayına düşer	Fonksiyonel	Mutlaka	Onaysız teklif gönderilemez	Satış müdürü
G-03	Temsilci yalnız kendi müşterilerini görür	Fonksiyonel olmayan (yetki)	Mutlaka	Başka temsilcinin müşterisi listede çıkmaz	Genel müdür
G-04	Onaylanan sipariş muhasebe programına aktarılır	Fonksiyonel (entegrasyon)	Olmalı	Sipariş muhasebede ayrıca girilmeden görünür	Muhasebe
G-05	Mevcut müşteri listesi Excel'den aktarılır	Veri taşıma	Mutlaka	Aktif müşteriler iletişim bilgileriyle taşınır	Satış operasyon
G-06	Aylık satış raporu Excel olarak indirilir	Fonksiyonel	Olabilir	Rapor bölge ve temsilci kırılımıyla iner	Genel müdür

Sütunlar hakkında kısa notlar:

• No: Toplantılarda ve tekliflerde maddeye atıf yapmayı kolaylaştırır.
• Tür: Veri taşıma ve entegrasyon maddelerini ayrı işaretlemek, bu kalemlerin teklifte görünür olmasını sağlar.
• Kabul kriteri: Teslimde neyin kontrol edileceğini baştan belirler.
• Kaynak: Bir madde tartışıldığında kime sorulacağını gösterir.

Teknik şartname hazırlarken sık yapılan hatalar

• Çözümü dikte etmek. "Sol üstte mavi bir düğme olsun" yerine ihtiyacı yazın. Ekran tasarımı, ihtiyacı bilen tasarımcının işidir.
• Belirsiz sıfatlar kullanmak. "Hızlı", "esnek" ve "kullanıcı dostu" test edilemez.
• Tek kişinin gözüyle yazmak. Yalnız yöneticinin anlattığı süreç, sahadaki gerçek işleyişten farklı olabilir.
• Veri taşımayı unutmak. Yıllardır Excel'de biriken müşteri ve ürün verisinin yeni sisteme aktarılması ayrı bir iştir.
• Raporları ve yetkileri sona bırakmak. Kimin neyi göreceği ve hangi raporun alınacağı, veri yapısını baştan etkiler.
• Kapsam dışını yazmamak. Yazılı olmayan her beklenti, teslimde tartışma konusu olur.
• Belgeyi okunmayacak kadar uzatmak. Ayrıntı netlik demek değildir. Her paydaşın kendi bölümünü okuyup onaylayabileceği bir düzen kurun.

Granobra'da şartnameyle nasıl çalışıyoruz

İstanbul merkezli ekibimizle özel yazılım, işletmeye özel CRM ve dijital ürün projelerine süreçleri sizinle birlikte haritalayarak başlıyoruz. Elinizde bir şartname varsa onu birlikte okuyarak, yoksa bu yazıdaki adımları birlikte yürüterek ilerliyoruz. Aşamaların sırasını proje aşamaları sayfamızda görebilirsiniz.

Kaynak kod ve lisans koşullarını teklifte açıklıyor, sözleşmede birlikte belirliyoruz. Web yazılım ve özel yazılım geliştirme hizmetimizin kapsamı da şartnamenizdeki gereksinimlere göre netleşiyor.

Sık sorulan sorular

Teknik şartnameyi kim hazırlamalı?

Şartnamenin sahibi yazılımı yaptıran işletmedir, çünkü süreçleri ve iş kurallarını en yakından o tanır. İçeriden bir proje sorumlusu belirleyip paydaşlardan bilgi toplamasını sağlayın. Teknik kısımlar için yazılım firmasından ya da bağımsız bir danışmandan destek almak mümkündür.

Teknik şartname ne kadar ayrıntılı olmalı?

Teklif verecek bir firmanın kapsamı tahmin edebileceği ve teslimde neyin kontrol edileceğinin belli olduğu kadar. Sayfa sayısı bir ölçü değildir; önemli olan her maddenin test edilebilir olmasıdır. Ekran tasarımlarının ve teknik mimarinin ayrıntısı genellikle proje başladıktan sonra, analiz aşamasında netleşir.

Şartname onaylandıktan sonra değişebilir mi?

Değişebilir ve çoğu projede değişir. Önemli olan değişikliğin nasıl yönetileceğinin baştan belli olmasıdır: kim talep eder, etkisi nasıl değerlendirilir, takvime ve bütçeye nasıl yansır. Bu süreç sözleşmede tanımlanırsa değişiklikler tartışma değil karar konusu olur.

Teknik şartname ile idari şartname arasındaki fark nedir?

Bu ayrım kamu ihalelerinden gelir. İdari şartname ihalenin usulünü, katılım koşullarını ve istenen belgeleri düzenler; teknik şartname ise alınacak mal ya da hizmetin özelliklerini tanımlar. Özel sektördeki bir yazılım projesinde bunun karşılığı, tedarik sürecini anlatan teklif talebi belgesi ile yazılımın ne yapacağını anlatan teknik şartnamedir.

User story ile gereksinim aynı şey mi?

User story, gereksinimi yazmanın bir biçimidir. Kullanıcı odaklı fonksiyonel gereksinimler için uygundur; performans, güvenlik ya da yasal yükümlülükler gibi maddeler ise ayrı cümlelerle daha net anlatılır. Çoğu şartnamede iki biçim birlikte kullanılır.

Şartnameniz hazırsa ya da yazmaya nereden başlayacağınızı birlikte netleştirmek istiyorsanız gereksinimlerinizi Granobra ile paylaşın. Projenizi konuşalım: teklif alın.