İçeriğe geç

Özel Yazılım

Yazılım Şartnamesi Hazırlama Rehberi: Başarılı Projelerin İlk Adımı

Yazılım şartnamesi hazırlama rehberi ile bütçe ve takvim sapmalarını önleyin. İhtiyaç analizi, kapsam dokümanı ve kabul kriterleri oluşturmanın somut adımları.

· 6 dk okuma

Kurumsal ofiste yazılım şartnamesi hazırlama ve teknik ihtiyaç analizi toplantısı yapan ekip

Kurumsal projelerin başarıyla tamamlanmasında en temel aşama, kod yazılmaya başlanmadan önce gerçekleşir. Doğru kurgulanmış bir yazılım şartnamesi hazırlama süreci, projenin bütçesini, teslim takvimini ve nihai kalitesini belirler. Birçok kurumsal yazılım projesi, yetersiz tanımlanmış ihtiyaçlar ve belirsiz beklentiler yüzünden hedeflenen süreyi aşar veya bütçe dışı maliyetlerle karşılaşır. Kapsamlı bir şartname, kurumun iş hedefleri ile yazılım ekibinin teknik planı arasında net bir zemin oluşturur. Bu rehberde, projenizi belirsizliklerden arındıracak, maliyetleri kontrol altında tutacak bir teknik şartnamenin nasıl hazırlanacağını adım adım inceleyebilirsiniz.

Yazılım Şartnamesi Nedir ve Projeler İçin Neden Gereklidir?

Yazılım şartnamesi (teknik adıyla yazılım gereksinim dokümanı veya Software Requirements Specification - SRS), geliştirilmesi planlanan bir sistemin işlevsel özelliklerini, kısıtlamalarını ve kabul kriterlerini detaylandıran resmi bir belgedir. Bu doküman, geliştiricilerin hangi özellikleri kodlayacağını belirlerken sistemin kimler tarafından, hangi iş akışlarında ve hangi performans kriterleriyle kullanılacağını da netleştirir. Projenin başında şirketiniz için özel yazılım mı hazır yazılım mı daha uygun sorusuna yanıt ararken, elinizde düzenli bir ihtiyaç listesinin bulunması doğru kararı vermenizi sağlar.

Şartname hazırlamanın sağladığı temel faydalar şunlardır:

  • Beklenti Farklılıklarını Önler: Talep eden birimlerin hedeflediği akışlar ile geliştirici ekibin teknik yorumu arasındaki farkları daha tasarım aşamasında görünür kılar ve uzlaştırır.
  • Bütçe ve Takvim Güvencesi Sağlar: Net bir yazılım kapsam dokümanı, geliştirici ekibin iş yükünü doğru planlamasına yardımcı olur. Belirsiz maddeler yerine somut isterlerin bulunması, sonradan çıkabilecek ek maliyetleri engeller.
  • Denetim ve Kabul Standardı Oluşturur: Dış kaynak kullanımı veya hizmet alımlarında, teslim edilen yazılımın kabul şartları bu dokümana göre değerlendirilir. Taraflar arasındaki iş birliğinde temel referans bu metindir.
  • Geliştirme Sürecini Netleştirir: Yazılımcıların çalışma sırasında iş mantığına dair tereddüt yaşamasını önleyerek planlanan takvime sadık kalınmasını sağlar.

Adım Adım Yazılım Şartnamesi Hazırlama Süreci

Kapsamlı bir yazılım şartnamesi hazırlama çalışması, ilgili birimlerin katılımıyla aşamalı olarak yürütülmelidir. Bu süreci beş temel aşamada yönetebilirsiniz:

1. Kapsamlı Yazılım İhtiyaç Analizi

İlk adımda, kurumun mevcut operasyonel durumu ve çözülmesi gereken temel iş süreçleri belirlenir. Yazılım ihtiyaç analizi yapılırken operasyonu yürüten çalışanlar, birim yöneticileri ve karar vericiler sürece dahil edilir. Şirketin mevcut manuel operasyonları veya eski yazılımları incelenir; kullanıcıların en çok zaman kaybettiği ya da hata yaptığı adımlar listelenir.

2. Paydaş Görüşmeleri ve Kullanıcı Hikayeleri (User Stories)

Yazılımı doğrudan kullanacak personelle birebir görüşmeler yapılmalıdır. Kullanıcı hikayeleri oluştururken şu kalıp tercih edilebilir: "Bir [Kullanıcı Rolü] olarak, [İşlem/Hedef] yapmak istiyorum, böylece [Fayda/Amaç] elde edebilirim." Örneğin; "Bir Depo Sorumlusu olarak, barkod okutarak stok girişi yapmak istiyorum, böylece manuel kayıt hataları azalsın." Bu yöntem, iş gereksinimlerinin teknik tarafa net aktarılmasını sağlar.

3. Fonksiyonel ve Fonksiyonel Olmayan Gereksinimleri Ayrıştırma

İhtiyaçlar belirlendikten sonra sistemin ne yapacağını tanımlayan fonksiyonel isterler ile sistemin teknik kalitesini belirleyen fonksiyonel olmayan isterler sınıflandırılmalıdır. Hangi modüllerin kurulacağı fonksiyonel bir konu iken, sistemin yanıt süresi veya veri tabanı erişim standartları fonksiyonel olmayan gereksinimdir.

4. Sistem Mimarisi ve Entegrasyon Haritası Çıkarma

Yeni yazılımların mevcut kurumsal sistemlerle uyumlu çalışması gerekir. Mevcut ERP, CRM veya muhasebe sistemleri ile bağlantı ihtiyaçları varsa kurumsal yazılım entegrasyonu adımları tanımlanmalı, veri aktarım protokolleri (REST API, Webhook gibi) dokümana eklenmelidir.

5. Kabul Kriterleri ve Değişiklik Yönetimi Kurallarını Belirleme

Her bir özelliğin tamamlanmış sayılması için hangi test senaryolarından geçeceği açıkça yazılmalıdır. Ayrıca proje başladıktan sonra gündeme gelebilecek yeni taleplerin nasıl değerlendirileceğine dair bir değişiklik prosedürü dokümana dahil edilmelidir.

Bir Teknik Şartnamede Mutlaka Yer Alması Gereken Başlıklar

Eksiksiz bir teknik şartname hazırlama sürecinde dokümanın belirli bir hiyerarşide yapılandırılması gerekir. Karışıklığı önlemek adına şartnamede bulunması gereken ana başlıklar şunlardır:

  • Projenin Amacı ve İş Hedefleri: Sistemin neden geliştirildiği, hangi operasyonel süreçleri iyileştireceği ve başarı ölçütleri açıklanır.
  • Kullanıcı Rolleri ve Yetkilendirme Matrisi: Sistemde hangi rollerin yer alacağı (Yönetici, Departman Sorumlusu, Operatör vb.) ve bu rollerin erişebileceği ekranlar tablo olarak sunulur.
  • Fonksiyonel Gereksinimler: Kullanıcı yönetimi, sipariş takibi, raporlama gibi sistem modülleri ve ekran akışları adım adım tanımlanır.
  • Fonksiyonel Olmayan Gereksinimler: Performans hedefleri, eşzamanlı oturum gereksinimleri, sunucu kaynağı sınırları ve erişilebilirlik kriterleri belirtilir.
  • Veri Güvenliği ve Mevzuata Uyum: Verilerin saklanma standartları, yedekleme planları, işlem kayıtları (log) ve kişisel verilerin işlenmesi konusunda Kişisel Verilerin Korunması Kanunu (KVKK) uyum kuralları yazılır.
  • Test, Kabul ve Teslim Süreçleri: Kullanıcı Kabul Testi (UAT) aşamaları, hata sınıflandırma seviyeleri ve onay protokolleri kurgulanır.
  • Bakım, Destek ve Hizmet Seviyesi (SLA): Canlı kullanıma geçiş sonrası hata düzeltme süreleri, güncelleme takvimi ve teknik destek koşulları listelenir.

Aşağıdaki tablo, şartnamede yer alması gereken fonksiyonel ve fonksiyonel olmayan gereksinim ayrımını göstermektedir:

KategoriTanımÖrnek Şartname Maddesi
Fonksiyonel GereksinimSistemin kullanıcıya sunduğu somut işlemler.Finans yöneticisi, seçilen tarih aralığındaki tahsilatları Excel ve PDF formatında dışa aktarabilmelidir.
PerformansSistemin işlem hızı ve kaynak kullanımı.Arama motoru, yoğun veri tabanında filtreleme sonuçlarını iki saniyenin altında listelemelidir.
Güvenlik ve UyumVeri koruma, kimlik doğrulama ve yasal kurallar.Kullanıcı oturumlarında iki adımlı doğrulama zorunlu tutulmalı, parolalar şifrelenmiş olarak saklanmalıdır.
KullanılabilirlikArayüz yapısı ve cihaz uyumluluğu.Tüm ekranlar masaüstü ve tablet çözünürlüklerine uyumlu (responsive) olarak tasarlanmalıdır.

Şartname Hazırlarken En Sık Yapılan 5 Hata ve Kontrol Ölçütleri

Kurumların şartname hazırlarken sıklıkla karşılaştığı hatalar ve bunları önlemek için dikkat edilmesi gereken noktalar şunlardır:

  1. Ölçülemeyen İfadeler Kullanmak: "Sistem hızlı ve modern olmalıdır" şeklindeki tanımlar teknik bir standart sunmaz. Bunun yerine sayfa yanıt süresi, işlem tamamlama adımları ve teknik standartlar netleştirilmelidir.
  2. Saha Gerçeklerini Dikkate Almamak: Doğrudan kullanıcılarla görüşülmeden hazırlanan yazılım proje gereksinimleri, devreye alma aşamasında personelin uyum sorunlarıyla karşılaşır. Süreçleri fiilen yürüten çalışanların görüşleri mutlaka alınmalıdır.
  3. Altyapı ve Bakım Süreçlerini Atlamak: Sadece arayüzlere odaklanıp barındırma mimarisi, yedekleme periyotları ve periyodik bakım şartlarını belirlememek, yayına geçiş sonrasında aksaklıklara neden olur.
  4. Entegrasyon İhtiyaçlarını Belirtmemek: Yazılımı izole bir yapıda düşünmek, ileride diğer kurumsal araçlarla bağlantı kurulmasını zorlaştırır. Gerekli API ve veri paylaşım standartları baştan tanımlanmalıdır.
  5. Kabul Kriterlerini Yazmamak: Sistemin hangi koşullarda başarılı sayılacağı ve hataların nasıl sınıflandırılacağı (Kritik, Normal, Düşük) yazılı değilse teslim alma aşamasında anlaşmazlıklar doğar.

Kapsam Kayması (Scope Creep) Riskini Önleme Yolları

Yazılım projelerinde bütçe ve süre aşımlarının başlıca nedeni kapsam kaymasıdır. Geliştirme sürerken ortaya çıkan ek istekler ve süreç içi değişiklikler, projenin planlanan takvimde bitmesini zorlaştırır.

Kapsam kayması plansız taleplerle başlar; yazılı kurallara bağlanmamış her yeni özellik, temel işlevlerin test edilmesini ve sistemin teslimini geciktirir.

Kapsam kaymasını yönetmek için şu adımları izleyebilirsiniz:

  • Aşamalı Dağıtım (Fazlandırma): Projenin ilk aşamasında temel iş operasyonlarını yürüten çekirdek özelliklere odaklanın. İkincil beklentileri sonraki geliştirme fazlarına planlayın.
  • Yazılı Değişiklik Yönetimi: Proje süresince gelen yeni taleplerin takvime ve maliyete etkisi analiz edilmeli, onay verilmeden geliştirme sürecine dahil edilmemelidir.
  • Ekran Taslakları (Wireframe) ile Doğrulama: Şartnameye temel ekran şemalarını veya akış diyagramlarını eklemek, ekipler arasındaki görsel algı farklarını ortadan kaldırır.

Şartname Sonrası: Doğru Yazılım Çözüm Ortağını Seçmek

Hazırladığınız yazılım kapsam dokümanı, yazılım firmalarından teklif alma sürecinde teknik bir standart sağlar. Firmalar aynı gereksinim listesi üzerinden bütçe ve süre planladığı için teklifleri doğrudan karşılaştırabilirsiniz. İhtiyaçlarınıza uygun bir yapı kurmak adına yalnızca kodlama yapan değil, iş süreçlerinizi analiz edebilen bir ekiple çalışabilirsiniz. Bu doğrultuda özel yazılım geliştirme süreçlerini tüm aşamalarıyla planlayan bir teknik kadro projenizi hedeflenen şekilde tamamlar.

Ayrıca ihtiyaç analizinin tarafsız bir bakışla oluşturulması için dijital dönüşüm ve BT danışmanlığı desteği alabilir, planlama aşamasındaki olası teknik riskleri önceden belirleyebilirsiniz. Doğru hazırlanmış bir teknik şartname, projenizin geliştirme ve kullanım aşamalarında güvenli bir çerçeve sunar.

İşletmenizin ihtiyaç duyduğu projelerde ihtiyaç analizinden teknik şartnameye, sistem mimarisinden geliştirmeye kadar her adımda Optimal Yazılım olarak Ankara'da yerinde, tüm Türkiye'de uzaktan erişimle yanınızdayız; projenizi başlatmak için bizimle iletişime geçebilirsiniz.

  • teknik şartname hazırlama
  • yazılım ihtiyaç analizi
  • yazılım kapsam dokümanı
  • yazılım proje gereksinimleri
  • özel yazılım planlama

SSS

Bu konuda sık sorulanlar

Sorunuzun yanıtını bulamadıysanız bizimle iletişime geçebilirsiniz.

Yazılım şartnamesi kim tarafından hazırlanmalıdır?

Şartname, projenin kullanılacağı iş birimi yöneticileri, operasyonel kullanıcılar ve kurum içi teknik ekipler tarafından ortaklaşa hazırlanır. Kurum bünyesinde teknik analiz deneyimi bulunmuyorsa, süreci objektif yönetmek adına bağımsız bir BT danışmanından destek alınabilir.

Fonksiyonel ve fonksiyonel olmayan gereksinim arasındaki fark nedir?

Fonksiyonel gereksinimler, sistemin kullanıcıya sunduğu doğrudan işlevleri (sipariş kaydı, raporlama gibi) içerir. Fonksiyonel olmayan gereksinimler ise sistemin hızı, veri güvenliği standartları ve eşzamanlı kullanım kapasitesi gibi teknik ölçütleri kapsar.

Yazılım şartnamesi hazırlandıktan sonra değişiklik yapılabilir mi?

Evet, yapılabilir. Ancak değişiklikler yazılı bir onay prosedürüne bağlanmalıdır. Her yeni talebin projeye getireceği ek maliyet ve süre etkisi analiz edilmeli, yönetim onayının ardından geliştirme takvimine dahil edilmelidir.

Detaylı bir şartname hazırlamak projenin başlangıcını geciktirir mi?

Şartname çalışması başlangıçta planlama süresi gerektirse de geliştirme aşamasındaki belirsizlikleri, hatalı tasarımları ve tekrar eden revizyonları önler. Bu sayede projenin genel tamamlanma süresini kısaltır.

Blog

İlgili yazılar

Projeniz için bizimle iletişime geçin

Talebinizi iletmeniz yeterli; ekibimiz en kısa sürede sizinle görüşme planlar. İlk görüşme ve keşif ücretsizdir.