Özel Yazılım Teknik Şartnamesi Nasıl Hazırlanır?

Özel yazılım teknik şartnamesi, bir yazılımın hangi ihtiyacı karşılayacağını, nasıl çalışacağını ve tamamlandığının hangi ölçütlerle değerlendirileceğini tanımlar. Hazırlamak için önce iş hedeflerini ve mevcut süreçleri netleştirin; ardından kullanıcıları, iş kurallarını, entegrasyonları ve kabul koşullarını somutlaştırın.

Şartname, yalnızca geliştiriciye verilen bir özellik listesi değildir. İş birimleri, teknik ekip ve karar vericiler arasında ortak bir referans oluşturarak kapsam belirsizliğini azaltır. Özellikle satış, satın alma, bayi ve tedarikçi süreçleri birbiriyle bağlantılıysa, gereksinimlerin iş akışları üzerinden tarif edilmesi önem kazanır.

Özel yazılım teknik şartnamesi neden önemlidir?

Bir yazılım projesinde aynı talep, farklı kişiler tarafından farklı yorumlanabilir. Örneğin “bayi sipariş durumunu görebilsin” ifadesi; hangi bayilerin erişeceği, hangi sipariş bilgilerini göreceği ve durumların ne zaman güncelleneceği açıklanmadıkça geliştirme için yeterince belirgin değildir. Teknik şartname, bu yorum farklarını proje başlamadan görünür hâle getirir.

İyi hazırlanmış bir doküman; kapsamı, öncelikleri ve başarı ölçütlerini ortaya koyar. Böylece ekipler hangi işlevlerin ilk sürümde bulunacağını, hangi konuların sonraki aşamalara bırakılacağını ve tamamlanan işin nasıl kontrol edileceğini bilir. Şartname tüm olasılıkları baştan çözmek zorunda değildir; değişikliklerin nasıl ele alınacağını da tarif edebilir.

• Beklentileri iş birimleri ve yazılım ekibi arasında ortaklaştırır.
• Kapsam dışı taleplerin ve sonradan fark edilen bağımlılıkların yönetilmesini kolaylaştırır.
• Test, onay ve teslim aşamalarında kullanılabilecek ölçütler sağlar.

Şartnameyi hazırlamadan önce hangi bilgileri toplamalısınız?

İlk adım, çözüm fikrini değil karşılanması gereken iş ihtiyacını tarif etmektir. Mevcut sürecin nasıl yürüdüğünü, nerede bekleme veya tekrar oluştuğunu ve bu durumun hangi kullanıcıları etkilediğini kaydedin. Sorunu mümkün olduğunca gözlemlenebilir ifadelerle anlatın; örneğin, “onay adımı farklı kanallardan takip ediliyor” gibi.

Bilgi toplarken yalnızca yöneticilerle görüşmek yeterli olmayabilir. Günlük işlemleri yapan kullanıcılar, istisnai durumlarla karşılaşan ekipler ve veriyi sağlayan teknik sorumlular farklı gereksinimleri ortaya çıkarabilir. Görüşme notlarını karar, varsayım ve açık soru olarak ayırın; doğrulanmamış varsayımları kesin gereksinim gibi yazmayın.

Kurumsal ticaret sistemlerinde satış, satın alma, bayi ve tedarikçi süreçleri farklı sorumluluklara ve kurallara sahip olabilir. Sipariş, fiyat, stok, onay ve teslimat bilgilerinin hangi sistemlerden geldiğini; kimlerin bu bilgilere eriştiğini belirlemek, gereksinimlerin doğru sınırlar içinde kalmasına yardımcı olur.

• İş hedefi: Yazılımla hangi iş sonucu veya süreç değişikliği hedefleniyor?
• Kullanıcılar: Sistemi kimler, hangi görev ve yetkilerle kullanacak?
• Mevcut süreç: İş bugün hangi adımlarla, hangi araçlar üzerinden ilerliyor?
• Bağımlılıklar: Hangi veriler, ekipler veya mevcut sistemler sürecin parçası?
• Kısıtlar: Güvenlik, erişim, çalışma ortamı veya operasyon bakımından hangi koşullar gözetilmeli?

Gereksinimler nasıl yazılmalı?

Gereksinimleri kullanıcı ihtiyacına ve sistem davranışına göre düzenleyin. İşlevsel gereksinimler sistemin ne yapacağını açıklar: kullanıcı sipariş oluşturabilmeli, yetkili kişi siparişi onaylayabilmeli veya belirli bir roldeki kullanıcı kayıtları görüntüleyebilmelidir. İşlevsel olmayan gereksinimler ise sistemin nasıl çalışması gerektiğini belirtir; güvenlik, erişilebilirlik, izlenebilirlik ve operasyonel devamlılık gibi konuları kapsar.

Her gereksinimi mümkün olduğunca tek bir davranışa odaklayarak yazın. “Sistem hızlı ve kullanıcı dostu olmalı” gibi ifadeler ortak bir test ölçütü sunmaz. Bunun yerine hangi ekran veya işlemin hangi kullanıcı için nasıl sonuç vermesi beklendiğini, ölçülebilir ve doğrulanabilir biçimde tanımlayın. Sayısal hedefler gerekiyorsa bunları varsaymak yerine ilgili paydaşlarla kararlaştırın.

Önceliklendirme yaparken gereksinimin iş değerini, zorunluluğunu ve başka işlere bağımlılığını birlikte değerlendirin. Her talebi ilk sürüme koymak kapsamı büyütür ve kritik işlevlerin sınanmasını zorlaştırabilir. Önceliklerin hangi gerekçeyle belirlendiğini de dokümana ekleyin.

• Belirsiz: Kullanıcı siparişleri kolayca takip edebilmeli.
• Daha açık: Bayi kullanıcısı, yetkisi bulunan kendi siparişlerinin güncel durumunu sipariş listesinde görebilmeli.
• Kontrol edilebilir: Yetkisi olmayan bir kullanıcı başka bir bayinin sipariş kaydına erişememeli.

Özel yazılım teknik şartnamesi adım adım nasıl hazırlanır?

Şartnameyi bir defada tamamlanan uzun bir metin yerine, geri bildirimle olgunlaşan bir çalışma dokümanı olarak ele alın. Her adımda ilgili iş ve teknik paydaşlardan doğrulama alın. Aşağıdaki sıra, kapsamı anlaşılır ve test edilebilir şekilde kurmaya yardımcı olur.

1. İş problemini ve hedeflenen sonucu tanımlayın. Başarıyı hangi işaretlerin göstereceğini belirtin; henüz ölçüm verisi yoksa bunu açık bir karar veya araştırma konusu olarak kaydedin.
2. Kullanıcı gruplarını ve yetkilerini çıkarın. Her rolün hangi işlemleri yapacağını, hangi bilgileri görüntüleyeceğini ve hangi işlemleri onaylayacağını listeleyin.
3. Mevcut ve hedef iş akışlarını çizin. Normal senaryoların yanında iptal, ret, eksik bilgi, tekrar deneme ve istisna durumlarını da yazın.
4. Gereksinimleri işlevsel, kalite, güvenlik ve entegrasyon başlıklarında düzenleyin. Her gereksinime açıklama, öncelik, sorumlu paydaş ve doğrulama yöntemi ekleyin.
5. Veri ve entegrasyon sınırlarını belirleyin. Hangi sistemin hangi veriyi sağlayacağını, verinin ne zaman güncelleneceğini ve hata hâlinde sürecin nasıl devam edeceğini netleştirin.
6. Kabul ölçütleri ve test senaryoları oluşturun. Her kritik gereksinimin hangi sonuçla karşılandığını gösterecek örnekler yazın.
7. Açık konuları, varsayımları ve değişiklik yönetimini kaydedin. Dokümanın sürümünü ve onaylayan paydaşları takip ederek güncel referansı belirgin tutun.

İş akışları, veri ve entegrasyonlar nasıl tarif edilir?

Bir iş akışını yalnızca ekran sıralaması olarak anlatmayın. Sürecin başlangıç koşulunu, işlemi başlatan rolü, karar noktalarını, olası sonuçları ve her sonuçtan sonra oluşan kayıtları belirtin. Örneğin sipariş onayında onayı kimin verdiği, ret durumunda ne olduğu ve ilgili kullanıcının nasıl bilgilendirileceği ayrı gereksinimler olabilir.

Veri tanımında alan adlarını sıralamanın ötesine geçin. Bilginin kaynağını, sorumlusunu, kimlerin görebileceğini ve değişikliklerin nasıl izleneceğini açıklayın. Aynı bilginin birden fazla sistemde tutulduğu durumlarda, hangi kaydın esas alınacağı özellikle netleştirilmelidir.

Entegrasyonlar için yalnızca bağlanılacak sistemin adını yazmak yeterli olmaz. Veri alışverişinin hangi iş olayında başlayacağını, başarılı ve başarısız yanıtların nasıl ele alınacağını ve geçici kesintilerde kullanıcıya ne gösterileceğini tarif edin. Teknik ayrıntıların bir bölümü analiz sırasında netleşebilir; bu durumda kararın sahibi ve tamamlanma koşulu şartnamede yer almalıdır.

Teknik şartname hangi durumda uygundur, ne zaman farklı bir yaklaşım seçilmelidir?

Kapsamı, iş kuralları ve kullanıcı rolleri tanımlanabilir olan; birden fazla ekibin aynı beklenti üzerinde çalışması gereken projelerde ayrıntılı bir şartname yararlıdır. Kurumsal satış, satın alma, bayi ve tedarikçi süreçlerinin kendine özgü kuralları varsa, bu kuralların yazılı ve doğrulanabilir olması geliştirme ile kabul aşamalarını destekler.

Buna karşılık, ihtiyacın henüz araştırıldığı veya kullanıcı beklentilerinin belirsiz olduğu bir çalışmada kapsamlı ve kesin bir dokümanı erkenden sabitlemek uygun olmayabilir. Böyle bir durumda önce süreç analizi, prototip veya sınırlı kapsamlı bir keşif çalışmasıyla belirsizlikleri azaltmak daha verimli olabilir. İş ihtiyacı standart bir paket çözümle karşılanabiliyorsa, özel geliştirme yerine mevcut çözümün uygunluğunu değerlendirmek de mantıklıdır.

Standart paketlere sığmayan satış, satın alma, bayi ve tedarikçi süreçleri için KMK’nın doğrulanmış çözüm tanımı, KMK Core üzerinde geliştirilen kuruma özel ticaret sistemidir. Bu tür bir yaklaşımın kapsamını değerlendirirken şartnamede iş kurallarını ve süreçler arası bağımlılıkları açıkça ortaya koymak gerekir. Çözümün kapsamını incelemek için kuruma özel ticaret sistemleri sayfasına göz atabilirsiniz.

• Özel geliştirme daha uygun olabilir: İş kuralları standart paketle karşılanmıyor ve süreçler kuruma özgü biçimde birbirine bağlanıyorsa.
• Standart çözüm daha uygun olabilir: Temel ihtiyaçlar piyasadaki bir paketle karşılanıyor ve farklılaştırıcı iş kuralı sınırlıysa.
• Önce keşif daha uygun olabilir: Kullanıcı, süreç veya veri gereksinimleri henüz doğrulanmamışsa.

Kabul ölçütleri ve sık yapılan hatalar

Kabul ölçütleri, bir gereksinimin hangi koşullarda tamamlanmış sayılacağını açıklar. “Sipariş yönetimi çalışıyor” demek yerine, belirli rolün geçerli bir sipariş oluşturması, gerekli alanların doğrulanması ve onay durumunun doğru şekilde kaydedilmesi gibi senaryolar tanımlayın. Ölçütler gerçek kullanım akışlarına dayanmalı ve test edilebilir olmalıdır.

Sık görülen hatalardan biri, şartnameyi ekran tasarımlarından ibaret görmektir. Ekranlar önemlidir; ancak arka plandaki iş kuralı, yetki kontrolü, veri kaynağı ve hata davranışı belirtilmezse uygulamanın nasıl davranacağı belirsiz kalır. Diğer bir hata, istisnai senaryoları ve kapsam dışı konuları hiç yazmamaktır.

Dokümanı gözden geçirirken her gereksinimin bir kaynağı, önceliği ve doğrulama yöntemi olup olmadığını kontrol edin. Gereksinimler arasında çelişki bulunup bulunmadığını, aynı kavramların tutarlı adlandırılıp adlandırılmadığını ve açık soruların sahibinin belirlenip belirlenmediğini de değerlendirin. Kurumsal ticaret sistemleriyle ilgili diğer içeriklere kurumsal ticaret sistemleri içerik kategorisinden ulaşabilirsiniz.

• “Kolay”, “hızlı” ve “kullanıcı dostu” gibi doğrulanması belirsiz ifadeleri tek başına bırakmak.
• Yetki, hata, iptal ve istisna senaryolarını kapsam dışında unutmak.
• Entegrasyonları yalnızca sistem adıyla tanımlayıp veri akışını açıklamamak.
• Öncelikleri ve kapsam dışı talepleri belirtmeden tüm istekleri aynı seviyede ele almak.

Etkili bir özel yazılım teknik şartnamesi, iş ihtiyacını açık süreçlere ve test edilebilir gereksinimlere dönüştürür. Kullanıcıları, istisnaları, veriyi, entegrasyonları ve kabul koşullarını birlikte ele almak belirsizliği azaltır. İhtiyaç henüz net değilse önce keşif yapın; kapsam belirginleştiğinde şartnameyi ekiplerin ortak ve güncel çalışma referansı hâline getirin.

Sık Sorulan Sorular