Kısa cevap: İyi bir yazılım şartnamesi 10 bölümden oluşur: firma tanıtımı, mevcut durum, amaç ve başarı kriterleri, kapsam ve kapsam dışı, fonksiyonel gereksinimler, fonksiyonel olmayan gereksinimler, entegrasyonlar, veri göçü, teslim ve destek beklentileri, teklif formatı ve takvim. 15 ila 25 sayfa yeterlidir ve en kritik bölüm kapsam dışı listesidir. Codefacture'ın hazırladığı ücretsiz şablonu yazının sonundan indirebilirsiniz.
Belirsiz talep, her firmanın kendi varsayımıyla fiyatladığı bir tahmin oyununa dönüşür.
Şartname yazmadan önce üç ön hazırlık
Sorunu tanımlayın, çözümü değil. "Bize CRM lazım" bir çözüm ifadesidir. "Tekliflerimiz üç ayrı Excel'de tutuluyor, hangi teklifin ne olduğunu takip edemiyoruz" bir sorun ifadesidir ve ikincisi doğru çözümü bulmayı sağlar.
Mevcut süreci haritalayın. Kim, hangi işi, hangi araçla, hangi sırayla yapıyor? Basit bir kutu ve ok şeması yeterlidir.
Ölçülebilir başarı ölçütü belirleyin. Ay sonu kapanışı 5 günden 1 güne insin, teklif hazırlama süresi yarıya insin gibi.
Şartnamenin 10 bölümü
Bölümİçermesi gerekenlerFirma ve proje tanıtımıSektör, çalışan sayısı, lokasyon, işlem hacmiMevcut durumKullanılan sistemler, sürümler, çözemedikleriAmaç ve başarı kriterleriÖlçülebilir hedeflerKapsam ve kapsam dışıDahil olan ve olmayan modüllerFonksiyonel gereksinimlerRol bazlı senaryolarFonksiyonel olmayan gereksinimlerPerformans, güvenlik, yedeklemeEntegrasyonlarSistem, yön, sıklık, muhatapVeri göçüKaynak, hacim, kaç yılTeslim, eğitim, destekFazlar, yanıt süresi, kaynak kodTeklif formatı ve takvimKalem kırılımı, tarihler
Kapsam dışı bölümü neden en kritik?
Neyin dahil olmadığını yazmak, neyin dahil olduğunu yazmak kadar önemlidir. Yazılmayan her şey iki tarafın farklı varsaydığı bir şeydir. Örnek: muhasebe entegrasyonu kapsamdadır, bordro modülü kapsam dışıdır.
Fonksiyonel olmayan gereksinim örnekleri
Eş zamanlı 120 kullanıcı desteklenmelidir
Liste ekranları 2 saniyenin altında yüklenmelidir
Rol bazlı yetkilendirme ve işlem logu bulunmalıdır
Günlük otomatik yedekleme yapılmalı ve geri dönüş testi uygulanmalıdır
KVKK kapsamında kişisel verilere erişim kaydı tutulmalıdır
Entegrasyonlarda neyi netleştirmelisiniz?
Entegrasyonlar tekliflerdeki en büyük belirsizlik kalemidir. Her entegrasyon için dört bilgiyi yazın: hangi sistem, hangi yön yani tek veya çift yönlü, hangi sıklık yani anlık, saatlik veya günlük, ve muhatap firma ile API dokümantasyonunun varlığı.
Gereksinim nasıl yazılır?
İyi gereksinim test edilebilir, kötü gereksinim yorum gerektirir.
Zayıf: "Sistem raporlama yapabilmelidir."
Güçlü: "Satış müdürü, seçtiği tarih aralığında temsilci bazında ciro, teklif sayısı ve dönüşüm oranını görebilmeli ve raporu Excel'e aktarabilmelidir."
Şu kalıbı kullanın: [Rol] olarak, [eylem] yapabilmeliyim, böylece [fayda] elde ederim.
Her gereksinime bir kabul kriteri ekleyin. Örnek gereksinim: depo sorumlusu olarak barkod okutarak mal kabul yapabilmeliyim. Kabul kriteri: barkod okutulduğunda ilgili ürün satırı otomatik gelir, miktar girilir, kayıt sonrası stok anlık güncellenir, tanımsız barkodda uyarı verilir ve kayıt engellenir.
Kabul kriteri, projenin sonunda "bu iş bitti mi" tartışmasını bitiren tek şeydir.
Gereksinimler nasıl önceliklendirilir?
SınıfAnlamıÖrnekZorunluOlmadan sistem kullanılamaze-Fatura entegrasyonuOlmalıÖnemli, ilk fazda ertelenebilirGelişmiş rapor tasarımcısıOlabilirBütçe uygunsaMobil uygulamaBu fazda yokBilinçli olarak dışarıdaİnsan kaynakları modülü
Bu sınıflandırma bütçenize göre kapsam daraltmanızı sağlar ve tedarikçinin fazlandırma önerisi getirmesine imkân tanır.
En sık yapılan beş hata
Ekran tasarımı dayatmak. Ne istediğinizi anlatın, nasıl görüneceğini tasarımcıya bırakın.
Kapsam dışını yazmamak. Sonraki ek ücret tartışmalarının kaynağı budur.
Sadece IT'nin yazması. Gereksinimler işi yapan kişilerden gelmelidir.
Aciliyeti gizlemek. Takviminiz sıkışıksa baştan söyleyin, fazlandırma önerisi alırsınız.
Aşırı uzun yazmak. 80 sayfalık tekrar dolu doküman okunmaz, 15 ila 25 sayfa net şartname daha etkilidir.
Şartname şablonunu indirin
Şablon on bölümün başlıklarını, örnek gereksinim yazımlarını, önceliklendirme tablosunu ve teklif karşılaştırma sayfasını içerir.
[Yayın öncesi eklenecek: .docx ve .xlsx şablon indirme bağlantıları. Bu sayfanın link kazanma potansiyeli tamamen bu dosyalara bağlı.]
Sık sorulan sorular
Yazılım şartnamesinde neler olmalı?
On bölüm olmalıdır: firma tanıtımı, mevcut durum, amaç ve başarı kriterleri, kapsam ve kapsam dışı, fonksiyonel gereksinimler, fonksiyonel olmayan gereksinimler, entegrasyonlar, veri göçü, teslim ve destek beklentileri, teklif formatı ve takvim. En kritik bölüm kapsam dışı listesidir.
Şartname kaç sayfa olmalı?
Orta ölçekli bir proje için 15 ila 25 sayfa yeterlidir. Uzunluk kalite göstergesi değildir, tekrar dolu 80 sayfalık dokümanlar okunmaz ve teklif kalitesini düşürür. Her gereksinimin test edilebilir olması sayfa sayısından önemlidir.
Şartname olmadan teklif alınabilir mi?
Alınabilir ancak gelen teklifler karşılaştırılamaz. En azından kapsam, entegrasyon listesi, kullanıcı sayısı ve veri hacmi netleştirilmelidir. Bu bilgiler olmadan verilen fiyat tahmindir.
Şartnameyi yazılım firması hazırlayabilir mi?
Evet, çoğu firma ücretli bir analiz çalışmasıyla bunu yapar. Bu çalışmanın çıktısı size ait olmalı ve başka firmalardan da teklif alabilmeniz için bağımsız kullanılabilmelidir. Sözleşmede bu maddeyi arayın.
Şartname sonradan değişirse ne olur?
Değişiklik normaldir. Önemli olan, değişikliklerin yazılı bir değişiklik talebi süreciyle yönetilmesi ve takvim ile bütçe etkisinin açıkça görülmesidir. Tanımsız küçük eklemeler, projelerin en yaygın bütçe aşım nedenidir.